WO2021135934A1

WO2021135934A1 - Blockchain accounting method and apparatus, node and storage medium

Info

Publication number: WO2021135934A1
Application number: PCT/CN2020/136600
Authority: WO
Inventors: 程强
Original assignee: 深圳市红砖坊技术有限公司
Priority date: 2019-12-31
Filing date: 2020-12-15
Publication date: 2021-07-08
Also published as: CN111159297A

Abstract

A blockchain accounting method and apparatus, a node and a storage medium. The blockchain accounting method comprises: an application chain miner participating in the election of proposal group members of a block to be mined, and if the application chain miner is elected as a proposal group member, sending a mining request to base chain miners; the application chain miner synchronizing base chain block information, and including same in a local base chain ledger, wherein the base chain block information comprises a result of the base chain miners electing a proposal group leader according to the mining request; the application chain miner participating in the election of verification group members of the block to be mined, and if the application chain miner is elected as a verification group member, verifying a block provided by the proposal group leader and broadcasting a check report; and the application chain miner receiving the check report, and if it is determined, according to the check report, that the block provided by the proposal group leader passes the verification, including the block in an application chain ledger. In the method, a mechanism of a base chain and an application chain jointly participating in mining is proposed, which is conducive to solving the problem of a waste of mining machine resources.

Description

Block chain accounting method, device, node and storage medium

Cross-references to related applications

This disclosure claims the priority of a Chinese patent application filed on December 31, 2019 with an application number of 201911410444.1, and the title of the invention is "a blockchain accounting method, device, node, and storage medium", the entire content of which is approved Reference is incorporated in this disclosure.

Technical field

The present disclosure relates to the field of blockchain technology, in particular to a blockchain accounting method, device, node, and storage medium.

Background technique

At present, the public blockchains led by Bitcoin in the industry generally have double waste: the first waste is the use of Proof of Work (PoW) algorithm, and a large number of meaningless calculations in the PoW algorithm lead to the mining process Excessive consumption of power resources, this problem can be solved by improving the consensus algorithm of the blockchain; the second waste is that the scarce mining machine resources only serve a single blockchain system, and the mining capacity of the mining machine has not been fully obtained. The use of. For example, in the existing Bitcoin system, there are millions of mining machines participating in mining, and the value of each mining machine may be as high as tens of thousands of RMB. However, due to the system implementation, it can only guarantee about 7 per second. The transaction capacity of the pen. As to how to improve the second waste of resources, no one has yet proposed a valuable solution.

Summary of the invention

The purpose of the present disclosure is to provide a blockchain accounting method, device, node and storage medium to improve the above technical problems.

In order to achieve the above objectives, the present disclosure provides the following technical solutions:

In the first aspect, the present disclosure provides a blockchain accounting method, which is applied to application chain miners, the method includes: participating in the selection of proposal group members of the application chain to be mined blocks; wherein, if it is determined that the application chain miner Members of the proposal group who are elected as the block to be mined in the application chain will send a mining request for the block to be mined in the application chain to the base chain miners, and the proposal group is for the application chain miners who have the right to send mining requests Collection; Synchronize the base chain block information, and incorporate the base chain block information into the local base chain ledger, the base chain block information is derived from the application generated by the base chain miner according to the mining request The base chain block of the leader of the proposal group of the chain to be mined, the base chain block information includes the election result indicating the leader of the proposal group; wherein, the leader of the proposal group has the application chain waiting Member of the proposal group for the right to mine the block; participate in the selection of the verification group member of the block to be mined in the application chain; wherein, if it is determined that the application chain miner is selected as the verification group member of the application chain to be mined block , Verify the block produced by the leader of the proposal group, and broadcast the inspection report to other application chain miners. The verification group is a collection of application chain miners who have the right to generate inspection reports. The output block includes the application chain to-be-mined block packaged by the leader of the proposal group; the inspection report is received, and if it is determined according to the inspection report that the block generated by the leader of the proposal group is verified, the The block is included in the application chain ledger.

In a second aspect, the present disclosure provides a blockchain accounting method, which is applied to base chain miners, and the method includes: according to a proposal sent by a member of the application chain to be mined block for the application chain to be mined block The mining request is to elect the leader of the proposal group for the block to be mined in the application chain; the base chain block storing the election results and the basis for the election is included in the base chain ledger.

According to the description of the above two methods, the application chain miners do not directly run the consensus algorithm to compete for the right to produce blocks, but send a mining request to the base chain miners after determining that they are members of the proposal group, and the base chain miners are elected by calculation The leader of the proposal group (that is, the application chain miner who has the right to produce blocks) records the election results and election basis in the base chain block, and then the application chain miner can obtain the information of the proposal group leader by synchronizing the base chain block information , And then participate in the selection of the members of the verification group, and judge whether the block passes the verification by collecting the verification report issued by the members of the verification group for the block produced by the leader of the proposal group, and if it passes the verification, the account will be kept. It is not difficult to see that the blockchain accounting methods provided by the above two aspects actually propose a set of new mechanisms in which the base chain and the application chain participate in mining. Miners), provide computing power services for many application chains, and assist application chains to complete the mining process, which can effectively improve the waste of mining machine resources in the existing blockchain system and has good social benefits.

On the other hand, the newly developed blockchain system is vulnerable to attacks due to the lack of support from mining machine resources. If a proprietary consensus algorithm is designed for such a blockchain system, although its security can be improved, it is bound to As a result, the mining machine lacks versatility and is difficult to be recognized by the market, and ultimately cannot solve the dilemma of the new system. If the blockchain accounting method provided by the above two aspects is used, the base chain can provide sufficient mining machine resources for the newly developed blockchain system to ensure its safe and stable operation.

In addition, in many blockchain systems, mining machines are not only used for mining, but can also be used to provide specific services to the outside world. It also requires a sufficient number of mining machines to ensure the stable operation of distributed services. If the blockchain accounting methods provided by the above two aspects are used, the base chain can provide sufficient mining machine resources for these blockchain systems to ensure the reliability of their services.

In the third aspect, the present disclosure provides a blockchain accounting method, which is applied to a synchronization node set in the base chain, and the method includes: receiving a proposal group leader who determines the block to be mined in the application chain sent by the base chain miner Base chain block, or receiving the block header of the base chain block and the election result list in the block body of the base chain block sent by the base chain miner or other synchronization nodes set in the base chain; Wherein, each entry in the election result list corresponds to the election result of the leader of the proposal group of a block to be mined on an application chain, including the election result of the leader of the proposal group of the block to be mined in the application chain ; Send the base chain block information derived from the base chain block to the application chain miner, the form of the base chain block information includes one of the following: the base chain block itself; the base chain block The block header of the base chain block and the election result list in the block body of the base chain block; the block header of the base chain block and the fragment data for the application chain in the block body of the base chain block; Wherein, the fragment data includes the election result of the leader of the proposal group for the block to be mined in the application chain in the election result list, and the election result and the block header of the base chain block are based on all the results. The merkle path between the merkle roots calculated from the election result list.

In the method provided by the third aspect, a synchronization node can be set on the base chain, and the synchronization node is used to synchronize block data including the results of the leader election of the proposal group from the base chain miners or other synchronization nodes, and the application chain miners can The base chain block information is further synchronized from the synchronization node for block generation and verification. The base chain block information can be a complete base chain block, or it can be simplified appropriately, and only the part required by the application chain miners in the base chain block is retained to reduce the bandwidth occupation during the data synchronization process.

In some scenarios, multiple application chain miners are allowed to share a synchronization node, and in some scenarios, some application chain miners do not directly synchronize base chain block information from the synchronization node, but synchronize from other application chain miners. In addition, in some schemes, the base chain does not need to set up independent synchronization nodes, and the application chain miners directly synchronize data from the base chain miners. These schemes can also be regarded as the base chain miners partially or fully implementing the function of the synchronization node. .

In a fourth aspect, the present disclosure provides a blockchain accounting device, which is configured on a mining node set in the application chain, and the device includes: a proposal group selection module for application chain miners to participate in the application chain to be mined blocks Selection of proposal group members; wherein, if it is determined that the application chain miner is selected as the proposal group member of the application chain to be mined block, then a mining request for the application chain to be mined block is sent to the base chain miner, so The proposal group is a collection of application chain miners who have the right to send mining requests; the block information synchronization module is used for the application chain miners to synchronize the base chain block information and incorporate the base chain block information into the local base chain. In the chain ledger, the base chain block information comes from the base chain block generated by the base chain miner according to the mining request to determine the proposal group leader of the application chain to be mined. The base chain block The information includes an election result indicating the leader of the proposal group; wherein, the leader of the proposal group is a member of the proposal group who has the right to produce blocks of the application chain to be mined; the verification group selection module is used for the application Chain miners participate in the selection of members of the verification group for the application chain to be mined; wherein, if it is determined that the application chain miner is selected as the verification group member of the application chain to be mined, the leader of the proposal group A block is generated for verification, and an inspection report is broadcast to other application chain miners. The verification group is a collection of application chain miners who have the right to generate inspection reports. The block produced by the proposal group leader includes the proposal group leader The packaged application chain block to be mined; the application chain accounting module, which is used by the application chain miner to receive the inspection report, and if it is determined according to the inspection report that the block produced by the leader of the proposal group has passed the verification, Then the block is included in the application chain ledger.

In a fifth aspect, the present disclosure provides a block chain accounting device, which is configured on a mining node set in the base chain, and the device includes: an election module for the base chain miners according to the proposal group of the block to be mined in the application chain The mining request sent by the member for the application chain to be mined block is the election proposal group leader of the application chain to be mined block; the base chain accounting module is used for the base chain miners to save the election results and The base chain block on which the election is based is included in the base chain ledger.

In a sixth aspect, the present disclosure provides a blockchain accounting device, which is configured on a synchronization node set in a base chain, and the device includes: an information receiving module for the synchronization node to receive a certain application chain sent by a base chain miner The base chain block of the leader of the proposal group of the block to be mined, or receiving the block header of the base chain block and the base chain block sent by the base chain miner or other synchronization nodes set in the base chain The election result list in the block body of the election result list; wherein, each entry in the election result list corresponds to the election result of the leader of the proposal group of a block to be mined on an application chain, including the application chain to be mined The result of the election of the leader of the proposal group of the block; an information sending module for the synchronization node to send the base chain block information derived from the base chain block to the application chain miners, and the base chain block information uses The form includes one of the following: the base chain block itself; the block header of the base chain block and the election result list in the block body of the base chain block; the block header of the base chain block and Fragment data for the application chain in the block body of the base chain block; wherein, the fragment data includes the election result of the leader of the proposal group for the block to be mined of the application chain in the election result list And, the merkle path between the election result and the merkle root calculated based on the election result list in the block header of the base chain block.

In a seventh aspect, the present disclosure provides a blockchain node, which is set on an application chain, the node includes: a memory and a processor, and computer program instructions are stored in the memory, and the computer program instructions are executed by the processor. When reading and running, execute the method provided by the first aspect or any one of the possible implementations of the first aspect.

In an eighth aspect, the present disclosure provides a blockchain node, which is set on a base chain. The node includes a memory and a processor, and computer program instructions are stored in the memory, and the computer program instructions are executed by the processor. When reading and running, execute the method provided by the second aspect or any one of the possible implementations of the second aspect.

In a ninth aspect, the present disclosure provides a blockchain node, which is set on a base chain, the node includes: a memory and a processor, and computer program instructions are stored in the memory, and the computer program instructions are executed by the processor. When reading and running, execute the method provided by the third aspect or any one of the possible implementations of the third aspect.

In a tenth aspect, the present disclosure provides a computer-readable storage medium having computer program instructions stored thereon, and when the computer program instructions are read and run by a processor, the first aspect and the second aspect are executed. Aspect, the third aspect, or the method provided by any one of the above three aspects.

Description of the drawings

In order to explain the technical solutions of the present disclosure more clearly, the following will briefly introduce the accompanying drawings that need to be used in the present disclosure. It should be understood that the following drawings only show certain embodiments of the present disclosure, and therefore should not be viewed. The work is to limit the scope. For those of ordinary skill in the art, without creative work, other related drawings can be obtained from these drawings.

Figure 1 shows a structural diagram of a blockchain system provided by the present disclosure;

Figure 2 shows a flowchart of a blockchain accounting method provided by the present disclosure;

Figure 3 shows a functional module diagram of the first blockchain accounting device provided by the present disclosure;

Figure 4 shows a functional module diagram of the second blockchain accounting device provided by the present disclosure;

Figure 5 shows the functional module diagram of the third blockchain accounting device provided by the present disclosure;

Fig. 6 shows a structural diagram of a blockchain node provided by the present disclosure.

Detailed ways

The technical solutions in the embodiments of the present disclosure will be described below in conjunction with the drawings in the present disclosure. It should be noted that similar reference numerals and letters indicate similar items in the following figures. Therefore, once a certain item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

It should be pointed out that in the description of the present disclosure, the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements , But also includes other elements that are not explicitly listed, or elements inherent to the process, method, article, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, article, or equipment that includes the element.

At the same time, the terms "first", "second", etc. are only used to distinguish one entity or operation from another entity or operation, and cannot be understood as indicating or implying relative importance, nor as requiring or implying these. There is any such actual relationship or sequence between entities or operations.

The blockchain accounting method provided in this disclosure aims to build a new mechanism in which the base chain and the application chain participate in mining: a base chain can gather mining machine resources (embodied as base chain miners) to provide many application chains Computing power services, assisting application chain miners to complete the mining process, the main purpose is to improve the problem of mining machine resource waste in existing blockchain systems (such as the Bitcoin system); in addition, the application chain determines the proposal group and verification group The random source of dependence is provided by the off-chain system (i.e. the base chain). The leader of the proposal group members is changed to the off-chain system (i.e. the base chain), and the off-chain system (i.e. the base chain) is the application chain mining process. Provide a clock source. These measures help to strengthen the security of the application chain. The meaning of the concepts of proposal group, verification group, random source and clock source will be explained later.

Fig. 1 shows a structural diagram of a blockchain system provided by the present disclosure. Referring to Figure 1, the blockchain system contains two kinds of blockchains, namely the base chain and the application chain. In a typical scenario, there is one base chain and one or more application chains, which means that the base chain is allowed At the same time, it provides computing power services for multiple application chains, so as to fully dispatch the computing power of the mining machines in the base chain. Of course, the process of providing computing power for each application chain by the base chain is similar, so in the following, the process of co-mining is mainly described in the case of one application chain. Figure 1 also shows only one application chain. It should be pointed out that when the concept of base chain is mentioned in this disclosure, it should generally be understood as a block chain in an abstract sense. It not only refers to the distributed ledger of the base chain, but also includes the nodes that constitute the base chain and the implementation of nodes. However, it does not rule out that the distributed ledger of the base chain is referred to as the base chain in some non-confusing positions in the following text; the concept of application chain should also be understood similarly.

With further reference to Figure 1, the application chain should include at least mining nodes. The application chain miners (for example, an application) are deployed on the mining nodes of the application chain, and the functions of the mining nodes are realized through the mining behavior of the application chain miners. In the following text, for the sake of simplicity, generally no longer specifically distinguish the two concepts of application chain mining nodes and application chain miners, but consider the two as one. Figure 1 shows four application chain miners: application chain miner A, application chain miner B, application chain miner C, and application chain miner D. In the solution of this disclosure, the application chain miners do not directly run the consensus algorithm locally to compete for the accounting right when mining, but transfer the task of competing for the accounting right to the base chain for processing, and the application chain miners only need to start from the base chain. Synchronize the result of competing for accounting rights, and perform block generation and verification work based on the result.

The base chain should include at least mining nodes. The base chain miners are deployed on the base chain mining nodes, and the functions of the mining nodes are realized through the mining behavior of the base chain miners. The two concepts of chain mining nodes and base chain miners are considered to be one. Figure 1 shows two base chain miners: base chain miner A and base chain miner B. During mining, application chain miners send mining requests to inform the base chain miners to determine the holder of the accounting rights for them. After the base chain miners determine the application chain miners with accounting rights according to the mining request, the results are saved In the base chain block.

Application chain miners need to know the results of competing accounting rights. In some implementations, relevant data can be directly synchronized from the base chain miners (the data can be a base chain block or its simplified form), for example, the application chain miner in Figure 1 D synchronizes data directly from base chain miner B. In other implementations, a dedicated synchronization node can also be set in the base chain, and application chain miners can synchronize related data from the synchronization node, and the data of the synchronization node is synchronized from the base chain miner or other synchronization nodes. Figure 1 shows two synchronization nodes: synchronization node A and synchronization node B. The data of synchronization node A is synchronized from synchronization node B, and the data of synchronization node B is synchronized from base chain miner A, application chain miner A and Application chain miners B can synchronize relevant data from the synchronization node B, so as to know the result of the competition for accounting rights. For the implementation of synchronizing related data directly from the base chain miners, it can also be considered that the base chain miners have realized part or all of the functions of the synchronization node at the same time.

In addition to recording the results of the application chain's competition for accounting rights, the base chain block can also contain other content, which may not be of much value to the application chain. Therefore, in the optional scheme, the base chain block held by the base chain miner is the original data. When the synchronization node synchronizes the data from the base chain miner, the original data can be simplified to a certain extent. The application chain miner synchronizes the data from the synchronization node. From time to time, it is possible to further simplify the data, minimize the network bandwidth occupied by the data during the transmission process, and improve the operating efficiency of the blockchain system.

In some common implementations, a dedicated synchronization node is set in the base chain for each application chain miner. The synchronization node and the application chain mining node can be implemented as independent nodes. To speed up data synchronization, the synchronization node and the application chain mining node can also be deployed in the same local area network; the synchronization node can also be implemented as the application chain mining node At the same node, the function of the application chain miner and the function of the synchronization node can be undertaken by two applications on the node respectively, or even merged into one application.

In other implementations, if there is no trust issue, multiple application chain miners can also share a synchronization node. For example, the application chain miner A and application chain miner B in Figure 1 share the synchronization node B, and it is very likely that the application chain Miner A and application chain miner B originally belong to the same organization and can be trusted with each other. It is reasonable to share synchronization nodes. In addition, application chain miners are allowed not to synchronize data from base chain miners or synchronization nodes, but to synchronize data from other application chain miners. For example, application chain miner C in Figure 1 synchronizes data from application chain miner B. For example, application chain miner C and application chain miner B belong to the same organization, and application chain miner C can trust application chain miner B's data. Such an implementation method is completely reasonable.

As mentioned above, in the solution of the present disclosure, the synchronization node mainly acts as an intermediary for the result of the application chain miners synchronizing and competing for the accounting rights from the base chain miners. As for the information sent by the application chain miners to the base chain miners during mining Whether the mining request needs to be transferred through the synchronization node is not limited. In some implementations, the synchronization node may also participate in base chain mining. At this time, the functions of the base chain miner and the synchronization node can be undertaken by two applications on the node respectively, or even merged into one application. . Moreover, the participation of synchronous nodes in base chain mining is also conducive to increasing the number of base chain miners. The greater the number of miners, the higher the security of the base chain. For different institutions, it is a common practice to set up their own dedicated synchronization nodes in the base chain (to ensure that the synchronized data is credible). If these synchronization nodes participate in mining, the miners on the base chain will be used by a large number of different institutions. Controlled (instead of being controlled by a few institutions like some existing blockchain system mining machine resources), so that mining on the base chain has natural decentralization characteristics, and the security of the entire blockchain system Greatly improved.

In some implementations, a management node can also be set in the base chain. The main role of the management node is twofold: one is to provide application chain registration services, and only the application chain base chain registered on the management node will provide computing for it. Strong support. In this process, the operator of the base chain may also charge a certain fee; the second is for the base chain miners to synchronize authorization and configuration information. The authorization information is the registration status of the application chain, and the base chain miners need to judge based on this information Whether it should respond to the mining request of the application chain miners, the configuration information mainly includes some preset parameters used by the base chain miners in the joint mining process, and these parameters should be kept as consistent as possible among the base chain miners.

The specific composition of the base chain and the application chain will be further explained below. In the prior art, Bitcoin belongs to a single-chain blockchain system, and its number of transactions per second (Transaction Per Second, TPS for short) is very limited, only about 7. At present, the industry has proposed many schemes using parallel chain mechanisms to improve the TPS bottleneck problem of single-chain blockchain systems. The more famous one is the Sharding technology in Ethereum. For the blockchain system in the present disclosure, each application chain or base chain can be a parallel chain (for simplicity, a single chain is also regarded as a special case where the number of parallel chains is 1). From the perspective of providing computing power, it can be considered that the parallel chains that constitute the base chain are independent of each other, and each parallel chain of the base chain can provide computing power for one or more application chain parallel chains.

When an application chain miner sends a mining request to the base chain, it should be clear which parallel chain of the base chain to send to the base chain miner. In one implementation, if it is assumed that N is the total number of parallel chains of the base chain (N is a positive integer), and the N parallel chains of the base chain are numbered sequentially from 0 to N-1, the application chain miners can be as follows The formula determines the parallel chain number of the base chain that provides computing power for the application chain in which you are located:

n=(ChainNoOffet+k)%N

Among them, n represents the determined parallel chain chain number of the base chain, ChainNoOffet is the chain number offset of the application chain where the application chain miners are located, this parameter is a preset value, each application chain has its own ChainNoOffet, and k is The chain number of the parallel chain of the application chain where the application chain miner is mining (if the application chain is a single chain, k can be 0), and% means the remainder operation. After calculating the parallel chain number n of the base chain, the application chain miner can send a mining request to the base chain miner on the parallel chain number n of the base chain. After the corresponding base chain miner receives the request, it will also be based on the request. The formula is verified (refer to the following content, the mining request includes information that can indicate which application chain and which parallel chain miner is sending the request, so that ChainNoOffet and k in the formula can be determined) whether you should respond It should be a mining request.

For the case where there are multiple parallel chains in the base chain, although these parallel chains are independent of each other in providing computing power services, in terms of software implementation, they can be implemented in one application or in multiple applications (e.g. , Each parallel chain is implemented by an application), which is not limited.

It needs to be pointed out that for the sake of simplicity in the following text, the base chain and the application chain are often referred to in general, and it is not clear whether it is the entire base chain or a parallel chain of the base chain, or whether it is the entire application chain or a piece of the application chain. Parallel chains can be specifically understood according to specific scenarios, and cannot be generalized.

Further, the base chain/application chain structure in the present disclosure can also be nested. For example, one base chain at the first level provides computing power support for 4 application chains, and these 4 application chains can be used as the second level. The base chains each provide computing power support for 16 application chains.

The solution of the present disclosure has no restriction on the specific type of blockchain used by the base chain or the application chain, as long as both the base chain and the application chain follow the longest chain rule. In a typical implementation, the base chain can be a public chain, and the application chain can be a public chain or a permission chain. Of course, if the base chain or the application chain directly adopts the existing blockchain system, it needs to be appropriately modified to meet the requirements of the common mining solution proposed in this disclosure.

It should be understood that the system structure in FIG. 1 is only an example, and should not be regarded as a limitation on the protection scope of the present disclosure. The above description of the common mining process is only a brief summary, and the specific implementation details will be given in the description of Figure 2.

Figure 2 shows a flowchart of a blockchain accounting method provided by the present disclosure. The method describes the process from generation to inclusion of a block on the application chain (application chain to be mined block) into the application chain ledger. The process is roughly divided into two phases: the proposal phase and the verification phase. The solution of this disclosure can be briefly summarized as follows: in the proposal stage, application chain miners elect members of the proposal group according to a preset algorithm, and only the members of the proposal group are eligible to be further elected as the leader of the proposal group and obtain the right to produce blocks (that is, the application chain is waiting to be mined). Block accounting rights), as to whether the right to produce blocks can be obtained depends on the result of the election of the leader of the proposal group by the base chain miners. The result is recorded in the base chain block. After the application chain miners synchronize the base chain block information It can be learned that the block produced by the application chain miner who becomes the leader of the proposal group will be broadcast in the application chain; in the verification phase, the application chain miner elects the members of the verification group according to the preset algorithm, and only the members of the verification group are eligible to enter. The block produced by the leader of the proposal group is verified and an inspection report is issued. The inspection report is broadcast in the application chain. If the application chain miners confirm that there are enough verification group members to approve the area where the leader of the proposal group has left the area according to the received inspection report The legality of the block is included in the local application chain ledger. Referring to Figure 2, the method specifically includes:

Step S100: Application chain miners participate in the selection of proposal group members for the block to be mined in the application chain.

Step S101: If it is determined that the application chain miner is selected as a member of the proposal group of the application chain to be mined block, then a mining request for the application chain to be mined block is sent to the base chain miner.

The above two steps are combined and explained together. The application chain to be mined block can be the next block in the application chain ledger that has been verified and accounted for. The proposal group refers to a collection of application chain miners who are eligible to compete for the right to produce blocks of the application chain to be mined. , Since only the members of the proposal group will send mining requests for the application chain to be mined blocks to the base chain miners, the proposal group can also be defined as a collection of application chain miners who have the right to send mining requests. In the proposal group, the app chain miner who finally obtains the right to produce the block to be mined in the app chain is called the leader of the proposal group, and the leader of the proposal group is elected by the base chain miners. See step S102 for details.

Each application chain miner can independently determine whether to be a member of the proposal group according to a preset algorithm, and does not depend on other application chain miners. In a typical implementation, the above-mentioned preset algorithm can use the Verifiable Random Function (VRF) algorithm. The core content of the VRF algorithm is the verification function VRF_prove and the verification function VRF_verify: calling VRF_prove(PrivateKey, info ) Can get a provable string proof, the proof obtained by VRF_prove for certain input (PrivateKey and info) is certain (the value obtained by multiple operations is the same), where PrivateKey is the private key of a public-private key pair K Key, info is a known string; calling VRF_verify(PublicKey,info,proof) can verify whether the proof is forged, where PublicKey is the public key in the public-private key pair K. If the proof is not forged (that is, the proof is made by PublicKey The corresponding PrivateKey is generated by calling VRF_prove), VRF_verify returns True to indicate that the verification is passed, otherwise it returns False to indicate that the verification fails. This disclosure mainly introduces the application of the VRF algorithm in the common mining process. For the detailed principle of the algorithm, reference may be made to the prior art, and no specific description will be given.

Application chain miners first call the proof function in the VRF algorithm based on their own private key (corresponding to the PrivateKey above) and the first election string determined by the preset rules (corresponding to the info above) to obtain the first provable string ( Corresponding to the proof above). After that, the application chain miner uses a preset rule to derive the first random value based on the first provable string, and determines whether the application chain miner is selected as a member of the proposal group for the block to be mined in the application chain based on the first random value. Suppose the derivation rules are deterministic (but the specific rules are not limited), so for the same input, the deduced first random value is also deterministic, and then the members of the proposal group obtained on the basis of the first random value The results of the election are also deterministic.

The above-mentioned first election string is a known string, and its acquisition rule is determined. The information of the leader of the proposal group elected by the base chain miners for the block to be mined in the application chain is recorded in a certain base chain block, which is said to be the base chain block of the proposal group leader who determines the block to be mined in the application chain , When the application chain miners participate in the proposal group leader, the base chain block is still in a state to be mined, but its height in the base chain can be determined (refer to the content below, the application chain also saves the base chain ledger ). In one implementation, the first election string may be: to determine the information in the first L block of the base chain block of the leader of the proposal group of the block to be mined in the application chain; where L is a positive integer, the so-called block The information in may be the hash value or random number recorded in the block header. For example, referring to the block header in Bitcoin, the first election string corresponds to the hash and nonce fields in the block header.

It is not difficult to find that the determination of the first election string depends on the base chain. The leader information of the proposal group elected by the base chain miners for each block of the application chain is recorded in the base chain block, and the application chain miners are synchronized to the base chain area. After the block information, the information can be saved on the mining node where the application chain miner is located to form a local base chain ledger for the application chain miner, which may be simplified compared to the base chain ledger of the base chain miner, but still contains For key information such as the block header and election results of the base chain block, the application chain miner can query the ledger to determine the content of the first election string.

Of course, other acquisition rules can also be used for the first election string, but as far as possible, it should be ensured that both application chain miners and base chain miners can obtain the string and get the same result (see below for the steps of base chain miners using this string) Therefore, it is a more reasonable choice to determine the first election string based on the information in the base chain ledger, because according to the above mentioned, both the base chain miners and the application chain miners store the base chain ledger ( Although the local save of the application chain miner may be a simplified version).

Further, after long-term research, the inventor found that the value of L should not be too large, which means that the first election string is derived from the information in the earlier base chain block, so that the value of the first election string The value can be determined very early. Once the adversary (which can refer to the malicious attacker on the blockchain system) learns the first election string early, he will have sufficient time to perform some cracking actions. Of course, the value of L is too small (for example, take 1). There are also some problems. It takes time for the application chain miners to synchronize the base chain block information. Therefore, the latest data in the local base chain ledger of the application chain miners may not be synchronized well. In addition, recent blockchain data is easily affected by the soft fork of the base chain, causing the value of the first election string to be affected (for example, current application chain miners and base chain miners or other application chain miners are waiting for the same application chain to be mined The string value obtained by the block is different).

Since the blockchain system is a distributed system, soft forks are an inevitable phenomenon. Due to the existence of soft forks, in the eyes of different base chain miners, the specified height of base chain blocks may not be the same, but Blocks that are farther away from the current time are easier to be unified into the same content, because the longest chain rule of the base chain will eliminate soft forks, that is, the base chain block that is the source of the first election string when L=2 The content identity is much higher than when L=1. When L=3, the identity of the base chain block as the source of the first election string is much higher than when L=2 (the same The probability of identity rises at an exponential level. For example, 6 blocks in Bitcoin are regarded as irreversible confirmation, the probability of identity is close to 100%, and the probability of non-identity is so small that it can be ignored). Therefore, comprehensive consideration can be taken when determining the first election string L=6. At this time, the first election string determined by the application chain miners and the base chain miners at the block at the designated height of the base chain can be basically considered to be the same. That is to say, the influence of the soft fork of the base chain on the value of the first election string is basically eliminated. At the same time, the first 6 blocks of the base chain block of the proposal group leader who determine the block to be mined on the application chain have been earlier. Included in the base chain ledger, sufficient time is reserved for the application chain miners to synchronize the base chain block information of the block, that is, taking L=6 also takes into account the communication delay factor, and the value is relatively reasonable, which is conducive to increasing the system. Robustness.

It should be pointed out that the above analysis is not to exclude implementations other than L=6. For example, the implementation of L=1 and L=2 is also feasible, because as time goes by, the soft fork will eventually suffer the longest The chain rules are eliminated, and the communication delay will also be eliminated, which does not affect the normal operation of the blockchain system.

In some implementation manners, it may be directly determined according to the first random value whether the application chain miner is a member of the proposal group of the block to be mined in the application chain. In other implementations, each application chain miner can calculate its own proposal group participation weight, and each application chain miner can determine whether he is an application chain based on the first random value and his own proposal group participation weight. The members of the proposal group of the block to be mined. Among them, the probability of the application chain miner being selected as a member of the proposal group is positively related to the value of the participation weight of the proposal group.

For example, the weight of the proposal group participation weight of a certain application chain miner can be the number of times the miner was elected as the leader of the proposal group in a preset historical time period. According to this definition, the more times the miner was elected as the leader of the proposal group in the historical time period The probability that a miner will be elected as the leader of the proposal group again is also higher, in return for his repeated honest mining. As mentioned in the introduction to the method of obtaining the first election string, the application chain miner will also save a base chain ledger locally, and the application chain miner can query the ledger to obtain statistics to obtain the current application chain miner elected within the preset historical time period. The number of times the leader of the proposal group.

As an optional solution, in order to increase the statistical speed of the number of elections, the application chain miners can also construct a query table based on the synchronized base chain block information. The table can be stored in the database or resident memory, and its content can include applications. The leader information of the proposal group of each block of the chain is convenient for the application chain miners to quickly query (no longer directly query from the local base chain ledger). The specific items of the inquiry form will be mentioned later.

The above-mentioned preset historical time period can be selected in different ways: for example, the continuous G2 (G2 is a positive integer) blocks of the base chain before the reciprocal G1 (for example, 36) blocks of the base chain are taken as the historical time period , Query the number of times that the miner of the application chain was elected as the leader of the proposal group in these blocks; for another example, take a difficulty adjustment period just past the base chain (the difficulty here refers to the difficulty of mining, for example, every 2016 block of Bitcoin is A difficulty adjustment period) before the consecutive G3 (G3 is a positive integer) difficulty adjustment period as the historical time period, query the number of times the application chain miners were elected as the leader of the proposal group in the base chain blocks generated during this period. It is not difficult to see that in the above two examples, the historical time period does not take the latest period of time at the current moment. The reason is that the communication delay and the soft fork of the base chain may affect the number of elections of the leader of the statistical proposal group. The two influencing factors have been analyzed before the first election string was explained, and will not be repeated.

Of course, other definitions can also be used for the weight of the proposal group, but it should be ensured that both application chain miners and base chain miners can calculate the weight and obtain the same calculation result (see the following for the steps of base chain miners using this weight), so , It is a reasonable choice to determine the weight of the proposal group based on the information in the base chain ledger, because both the base chain miners and the application chain miners have the base chain ledger.

In some implementations, the first accounting weight parameter can also be preset on the application chain. A value of 0 means that the newly added application chain miners are prohibited from participating in mining; otherwise, if the first accounting weight takes a non-zero value, it means Allow newly joined application chain miners to participate in mining. When it is calculated that the application chain miners have not been elected as the leader of the proposal group within the above-mentioned preset historical time period (for newly joined application chain miners, they may still be If they are not involved in mining), their proposal group participation weight (the value is 0 at this time) can be set as the first accounting weight, so that they can be elected as a proposal group member with a lower probability.

In some implementations, the application chain can also preset the parameter of the proposal group’s maximum participation weight, that is, set an upper limit for the proposal group’s participation weight. If the calculated proposal group’s participation weight exceeds the upper limit (for example, application Chain miners have been elected as the leader of the proposal group for many times in the historical time period, and the proposal group’s participation weight is greater than the preset maximum participation weight of the proposal group), then the proposal group participation weight is set to the maximum participation weight of the proposal group . Avoid a certain application chain miner who is deeply involved in mining to have too much advantage in the selection of proposal group members, and deprive other application chain miners of the opportunity to be elected as members of the proposal group.

Application chain miners determine whether they are members of the proposal group of the block to be mined in the application chain according to the first random value and their own proposal group participation weight. There are also different implementation methods. In one implementation method, it can be implemented as follows:

First, use the following formula to calculate the second random value RandValue2:

RandValue2=(RandValue1%ExpectedRange1)+priority1

Among them, RandValue1 is the first random value, ExpectedRange1 is the preset range value, priority1 is the weight of the proposal group participation, and% represents the remainder operation. The function of ExpectedRange1 is mainly to adjust the value of RandValue1 to a reasonable range, because the randomness of RandValue1 makes the value may be very large, which is not in the same order of magnitude as priority1. If RandValue1 is directly used for calculation, it may cause whether to add priority1 The final result has no effect.

If the calculated RandValue2 satisfies the following conditions, it is determined that the current application chain miner is selected as the proposal group member of the application chain to be mined block:

RandValue2>ExpectedRange1-(ExpectedRange1*1/M1)

Among them, M1 is the preset filtering ratio. For example, if M1 is 10, about 1/10 (in a probability sense) of all miners in the application chain will be selected as members of the proposal group.

It should be understood that the above two formulas are only examples. In different implementations, other forms can also be adopted. For example, priority1 is combined into the formula by product (currently by addition), or RandValue2 Less than a certain value is used as a condition for being elected as a member of the proposal group (currently greater than a certain value), and so on.

If an application chain miner confirms that he is a member of the proposal group of the application chain to be mined, he will send a mining request for the application chain to be mined to the base chain miner. As mentioned above, in different implementations , The application chain miner may send a request directly to the mining node where the base chain miner is located, or may send a mining request to the synchronization node on the base chain. The node that receives the mining request first in the base chain will send the mining request at Broadcast in the base chain, and eventually all base chain miners will receive it. If the base chain is composed of multiple parallel chains, before sending a mining request, the application chain miner needs to determine which base chain miner on the parallel chain to send the request to, otherwise the request will not be accepted. The determination method is shown in the illustration. It has been explained at 1 o'clock and will not be repeated here.

The mining request includes proposal candidate information. The concept of proposal candidate information will be used in many places in this system. Its content includes: application chain identification, parallel chain chain number, height of the block to be mined in the application chain, and determination of the leader of the proposal group The height of the base chain block, the public key of the application chain miner, and the first provable string.

Among them, the application chain identifier refers to the identifier of the application chain where the member of the proposal group that sent the mining request is located (used to uniquely mark an application chain), and the parallel chain number refers to where the member of the proposal group in the parallel chain that constitutes the application chain mines. The number of the parallel chain (if the application chain is a single chain, this item can be fixed to 0), the height of the base chain block that determines the leader of the proposal group refers to the base chain of the proposal group leader who determines the block to be mined in the application chain The height of the block, the public key of the application chain miner refers to the public key of the proposal group member who sent the mining request, and the first provable string refers to the first provable string that the application chain miner relied on when elected as a member of the proposal group . Of course, the proposal candidate information can also include other information items, such as the second random value that the application chain miners rely on when they are elected as members of the proposal group. Although the second random value can also be derived using the first provable string, it needs to be For certain operations, in some occasions where the security requirements are not too high, the second random value can also be used directly for verification and other behaviors, without the need to derive it again. The purpose of each information item in the proposal candidate information will be explained in the subsequent steps, and will not be expanded here.

Step S102: The base chain miners elect the leader of the proposal group according to the mining request for the application chain to be mined block sent by the proposal group members of the application chain to be mined block.

After the base chain miner receives a mining request sent by an application chain miner, it must first confirm whether to respond to the request. If it is confirmed to respond to the request, the request will be used as a proposal to elect the application chain to be mined. The basis of the group leader. The content to be verified includes at least the following two:

First, the base chain miners determine whether the application chain corresponding to the identifier is supported by the base chain based on the application chain identifier in the mining request.

As mentioned in the illustration of Figure 1, in common implementations, a certain application chain must be registered on the management node in the base chain before the base chain will provide services for it. The registration information will be synchronized to each base chain miner. For example, each base chain miner can locally maintain a set of application chain identifiers corresponding to the registered application chain. If the base chain miner finds the application chain in the current mining request If the identifier is in the set, it means that the application chain corresponding to the identifier has been registered, and the verification of this item is passed, otherwise it is not passed.

If you consider the case where the base chain and the application chain are parallel chains, the situation may be more complicated. The base chain miners may also need to calculate the base chain parallel chain chain number n according to the application chain identifier R and the parallel chain chain number k in the mining request. =(ChainNoOffet+k)%N, if the calculation result is consistent with the real parallel chain number, confirm that you can provide computing power services to the kth parallel chain under the application chain identified as R (only refers to this verification Pass), otherwise confirm that you cannot provide computing power services to the kth parallel chain under the application chain identified as R. Among them, the identifier R is used to determine the value of the ChainNoOffet parameter in the formula, because this parameter is set for each application chain.

Second, the base chain miner first determines the first election string that the application chain miner who sent the mining request depends on when it is elected as the member of the proposal group according to the height of the base chain block that determines the leader of the proposal group in the mining request; Then, based on the application chain miner’s public key in the mining request, the first proof string, and the first election string calculated by myself, the verification function in the VRF algorithm is called to verify whether the first provable string in the mining request is If forged, the verification function outputs True, indicating that the first provable string is not forged, and False indicates that the first provable string is forged.

Among them, the method of obtaining the first election string has been introduced in the previous article, but the calculation was performed by the application chain miners before, and here is the calculation by the base chain miners. In the implementation methods listed above, the source of the first election string The information in the base chain block is obviously easy to obtain for the base chain miners who have the base chain ledger locally, and the details will not be elaborated. If the output result of the verification function shows that the first provable string is not forged, the verification of this item is passed, otherwise the verification of this item is not passed.

In some optional schemes, you can also add a third verification content: the base chain miner first uses the hash algorithm to calculate according to the application chain identification, the parallel chain chain number, and the application chain miner’s public key in the mining request. The miner ID of the app chain miner who sent the mining request, which is used to uniquely mark an app chain miner. Then, the base chain miner judges whether the calculated miner ID is in the blacklist configured by the base chain for the application chain. The content of the blacklist can be a collection of a series of miner IDs. If the miner ID of the app chain miner who sends the mining request is In the blacklist, the base chain miners should refuse to provide services for them, that is, the verification fails, otherwise the verification is passed.

The following is an example of a typical application scenario of the blacklist. For application chains with clear participants (that is, it can be roughly determined from which institutions the miners of the application chain come from), mining can be opened for a period of time, and then new additions can be prohibited through configuration Miners of the application chain mining (for example, reset the first accounting right mentioned above to 0), and then include the application chain miners who have participated in mining but come from unknown institutions into the blacklist to avoid possible security risks.

In some optional schemes, you can also add a fourth verification content: the base chain miner first uses the hash algorithm to calculate according to the application chain identification, the parallel chain chain number and the application chain miner’s public key in the mining request. The miner ID of the app chain miner who sent the mining request. Then, the base chain miner judges whether the calculated miner ID is in the real name list configured by the base chain for the application chain. The content of the real name list can be a collection of a series of miner IDs. If the miner ID of the application chain miner who sends the mining request is In the real-name list, the base chain miners should agree to provide services for them, that is, the verification of this item is passed, otherwise the verification of this item is not passed. This verification is applicable to situations that require real-name mining by application chain miners.

If all the above verification contents are passed, the base chain miners accept the current mining request and perform subsequent processing. Before introducing the next steps, let's make some explanations on the management nodes set up in the base chain mentioned earlier:

There are two main functions of the management node: The first function is authorization information management. The management node provides external application chain registration services. If the manager of the application chain wants the operating application chain to be supported by the base chain’s computing power, it should initiate a registration with the management node. If the management node agrees to the application chain’s registration request, it can register with the base chain. The miner issues authorization information (the issue here can be actively issued by the management node, or the base chain miner requests it to issue), and the content of the authorization information includes the information of the registered application chain (for example, the application of these application chains). Chain identification).

The second function of the management node is configuration information management. The configuration information includes some preset parameters used by the base chain miners, such as the preset range values, preset filtering ratios, and first-time The accounting weight, the maximum weight of the proposal group and a number of parameters mentioned later. Although only the use of these parameters on the application chain has been introduced before, some or all of the parameters will also be used on the base chain. The same parameters should be as consistent as possible on the application chain and the base chain (because the parameters are applied in the base chain). The synchronization between the chain and the base chain takes time, so it is not ruled out that the value of the same parameter is different on the base chain and the application chain at some time, but the parameters can be designed with a certain margin), and the specific parameters are maintained. The method of consistent value is not limited in the present disclosure. Each base chain miner can synchronize configuration information from the management node, or it can be actively broadcast by the management node.

Authorization configuration information (abbreviation of authorization information and configuration information) is very important for the normal block generation of the application chain. Therefore, in some implementations, the management node can strictly number it to ensure the integrity of the data. For example, each modification operation of each parameter in the configuration information is recorded, and each operation behavior is sequentially numbered, so that all modification behaviors of the parameter can be traced back. For another example, for each parallel chain of the base chain, there are one or more parallel chains of its own service (these parallel chains can have their own set of configuration information), so the parallel chains of the base chain can also be Carry out the number, respectively carry on the configuration information management.

The authorized configuration information may be adjusted during the operation of the blockchain system. For example, the administrator of the application chain can submit the latest values of the parameters in the configuration information to the management node. In a common implementation, due to data transmission overhead and system stability considerations, after the authorization configuration information is updated, it will not be synchronized from the management node to the base chain miners in real time, but will be synchronized at a specified time. For example, base chain miners can query the management node at the beginning of the difficulty adjustment period of the base chain whether the locally saved authorization and configuration information is the latest version, if not the latest version, synchronize the latest version of the authorization and configuration information from the management node; among them, Base chain miners make a query every preset number of difficulty adjustment cycles. When the management node sends authorization and configuration information to the base chain miners, it can also sign with its own private key to prevent the information from being tampered with.

The base chain miners continuously collect and cache the mining requests sent by the miners of each application chain. These mining requests may be for blocks of different heights in the application chain (specified by the height of the block to be mined in the application chain in the mining request) . When the base chain miners package the base chain blocks, they first determine the new height of the application chain to be mined according to the highest block of the application chain recorded in the base chain ledger and the leader of the proposal group has been selected (named as the new height is In order to distinguish it from the old height later, it has no special meaning), that is, to determine the election result of the application chain block of which height is to be recorded in the currently packaged base chain block. In most cases, since the block heights in the blockchain increase sequentially, the height of the highest block of the application chain recorded in the base chain ledger and the leader of the proposal group has been selected plus one to get the new height, but In some implementations, to allow empty blocks to be added to the application chain, you need to add 2 or more to get a new height. Basechain miners can maintain a variable that is used to record the height of the highest block in the application chain that has selected the leader of the proposal group recorded in the basechain ledger. Of course, they can also query the basechain ledger every time a block is generated. Regarding the existence of empty blocks in the application chain, you can refer to the following text about the content of the base chain and the application chain generating blocks at the same frequency.

After determining the new height, the base chain miners select the mining request that matches the new height from the cached mining requests and include them in the waiting set for the new height. The so-called matching refers to the block to be mined in the application chain in the mining request. The height item is consistent with the new height.

After that, the base chain miners judge whether the number of requests in the set to be elected for the new height is not less than the preset minimum number of miners. If the minimum number of miners is not reached, then the leader of the proposal group will be elected for the block of the new height of the application chain. If a person fails, the processing method for failure is described in step S103. If the minimum number of miners is reached, the application chain is determined according to the first provable string in each mining request in the set to be elected for the new height The leader of the proposal group for the new height block. For different application chains, the minimum number of miners can take different values, such as a value between 10 and 50.

Among them, the parameter of setting the minimum number of miners is used to verify whether enough application chain miners agree with the current mining status, because honest application chain miners only pass the verification of the previous block of the application chain to be mined. Will request to mine the next block, and then it is possible to issue a mining request for the block to be mined in the application chain. If the number of requests in the waiting set for the new height is less than the minimum number of miners, it indicates that there are not enough Of application chain miners agree that currently mining blocks of new heights in the application chain are needed, and the elected leader of the proposal group is not effective.

As mentioned above, the base chain miners elect the leader of the proposal group when they pack the base chain blocks. However, when the base chain miners pack the base chain blocks, it may be different according to the different mechanisms adopted by the base chain. This disclosure is about this. It is not limited. For example, there may be multiple base chain miners packing the base chain blocks at the same time. Of course, in the end, only the blocks packaged by the base chain miners who have obtained the bookkeeping right will be recognized; for another example, each base chain miner first competes for the bookkeeping right, only to obtain Only the base chain miners with bookkeeping rights will package the base chain blocks, and so on.

Based on the first provable string in each mining request in the set to be elected for the new height, the base chain miners determine the leader of the proposal group for the block of the application chain at the new height. There are different implementation methods:

For example, if the application chain miners used the second random value when selecting the members of the proposal group, the base chain miners can first calculate according to the first provable string in each mining request in the set to be elected for the new height The specific process of the second random value corresponding to the mining request can be: first derive the first random value based on the first provable string using preset rules, and then according to the first random value and the application chain that sent the mining request The second random value is calculated for the weight of the miner's proposal group participation (for the calculation formula, please refer to the previous article). As mentioned earlier, the weight of the proposal group participation can be determined based on the information in the base chain ledger, for example, it is defined as the number of times the application chain miners are elected as the proposal group leader in a preset historical time period. The base chain miners store the base chain ledger locally, which can naturally count the number of elections of the application chain miners. Of course, in order to increase the speed of counting the number of elections, the base chain miner can also build a database or memory table based on the information in the base chain ledger. Convenient for inquiries.

After the base chain miners calculate the second random value corresponding to each mining request, they will further use a preset selection condition to filter out a second random value that meets the conditions, and then the second random value corresponding to the mining The sender of the request is determined as the leader of the proposal group of the block to be mined in the application chain. The selection condition can be the maximum or minimum calculated second random value, which is not limited, but for the sake of simplicity, the following is an example of selecting the largest second random value.

In an optional solution, if the second random value corresponding to multiple mining requests is the largest, further information that can identify the identities of the members of the proposal group corresponding to these mining requests can be obtained (for example, The public key or the hash value of the public key of the members of the proposal group, where the miner’s public key is carried in the mining request), and use the obtained information to further compare according to certain rules, for example, let the public key or the public key hash The person with the greatest value is elected as the leader of the proposal group.

In an optional scheme, the base chain miners can further check whether the largest second random value is greater than the preset smallest random value. If it is greater than the smallest random value, the leader of the proposal group will be formally determined that the election is successful, otherwise The block election proposal group leader of the new height of the application chain fails, and the processing method for the failure is described in step S103.

Among them, the parameter of setting the minimum elected random value is used to increase the difficulty of the attack. Even if the adversary forges a large number of accounts to carry out witch attacks, the application chain miners corresponding to these accounts can only be elected as the leader of the proposal group with a low probability, especially for the proposal group participants. The selection weight is based on the number of times the leader of the proposal group has been elected. According to the calculation rule of the second random value, the new application chain miner has a small participation weight corresponding to the proposal group, and the final calculated second random value is also small, so It is likely to be excluded from the process of verifying the minimum random value of the election and will not be selected as the leader of the proposal group. Of course, there are other methods to prevent Sybil attacks. For example, when basechain miners discover that a large number of application chain miners who have never participated in mining suddenly request mining, they directly reject the mining request of these application chain miners. In an optional solution, a continuous mining flag parameter can be set for each application chain. This parameter can take at least two values (such as True and False), which respectively indicate that miners of the same application chain are allowed to be successively elected leaders of the proposal group And the same application chain miner is not allowed to be continuously elected as the leader of the proposal group. The continuous election here means that a certain application chain miner is selected as the leader of the proposal group in two consecutive blocks (empty blocks are not considered) of the application chain. If the continuous mining flag indicates that the same application chain miner is not allowed to be successively elected as the leader of the proposal group, the base chain miner will determine whether the leader of the proposal group is the same after determining the leader of the proposal group according to the largest second random value. The proposal group leader selected in the last proposal group leader election of the application chain, if yes, then re-determine the proposal group leader, and determine the application chain miner corresponding to the mining request with the second largest random value calculated as The leader of the proposal group of the block to be mined in the application chain. Forbidding miners of the same application chain to be continuously elected as the leader of the proposal group is beneficial to improve the security of the blockchain system, because it is more difficult for adversaries to continuously obtain the right to keep accounts, combined with the longest chain rule, double-spending attacks will be more difficult to implement.

Step S103: The base chain miner incorporates the base chain block storing the election results of the application chain to be mined blocks and the basis of the election into the base chain ledger.

If in step S102, the leader of the proposal group for the block to be mined in the application chain is successfully selected, the base chain miners union will pack the election results and election basis into the base chain block, but it needs to be noted that some consensus is adopted in the base chain During the algorithm, multiple base chain miners will package the base chain blocks. These base chain blocks all record the election results of the blocks with the new height of the application chain. In the end, only the blocks produced by the base chain miners who have obtained the accounting rights will be It is transmitted in the base chain and incorporated into the base chain ledger, that is to say, the base chain block described in step S103 actually refers to the block produced by the base chain miner who has obtained the accounting right, and the member of the proposal group is elected in step S102 Base chain miners are those who compete for the right to bookkeeping, not necessarily those who have obtained the right to bookkeeping.

The following describes the election results of the application chain to be mined in the base chain block and the possible forms of the election basis. Among them, the election results are mainly used to indicate the identity of the leader of the proposal group and which application chain area the leader of the proposal group is targeting. For block elections, the election basis is mainly used to record the credentials of the leader of the election proposal group, so that others can verify whether the election result is correct.

In one implementation, the election result includes the proposal candidate information obtained from the mining request sent by the leader of the proposal group of the application chain for the block to be mined in the application chain, and each base chain block has the maximum value for each application chain. Record an election result. In other words, the election results of two different blocks on the application chain must be recorded in two different base chain blocks. The election result is stored in the block body of the base chain block as an entry in the election result list. The election result list can include multiple entries, and each entry corresponds to a block to be mined on the application chain. Election results. In some existing blockchain systems, transactions are stored in the block body of a block, and a merkle tree can be constructed by performing multi-level hash operations on these transactions, and the merkle root (the root node of the merkle tree) is stored in the block header. In this disclosure, the structure of the base chain block can also be designed in a similar way, that is, the table items of the election result list are stored in the block body of the base chain block, and the merkle root calculated based on these table items is stored in the area. In the block header, it is recorded as merkle_root1 for the convenience of the following description.

The election basis includes a collection of proposal candidate information obtained from mining requests in the set to be elected for a new height, because the leader of the proposal group of the block to be mined in the application chain is selected based on the mining request in the set to be elected , So it is reasonable to use the proposal candidate information in these mining requests as the basis for election. Optionally, the proposal candidate information corresponding to the leader of the proposal group may not be included in the election basis, because the information is already included in the election result. Election basis is stored in the block body of the base chain block as an entry in the election basis list. For each proposal candidate information in the same entry, due to the application chain identification, parallel chain chain number, and application chain waiting information. The three pieces of information about the height of the mining block are the same, so it can be stored only once to save storage space. The election basis list can include multiple entries, and each entry corresponds to the election basis of a block to be mined on an application chain. In the same base chain block, the election result list and the election basis list have the same length, and each table item also has a one-to-one correspondence. The block body of the base chain block stores the entries of the election basis list, and the merkle root calculated based on these entries is stored in the block header, which is recorded as merkle_root2 for the convenience of the following description.

Since the block header contains merkle_root1 and merkle_root2, it means that merkle_root1 and merkle_root2 will also be used as the source strings when calculating the hash value of the block. That is to say, once the content of the base chain block is determined, the list of election results and the basis for election The lists are all incorporated into the non-tamperable mechanism of the blockchain. Here, merkle_root1 and merkle_root2 are recorded in the block header of the base chain, indicating that the base chain adopts a double merkle tree structure.

In the solution of the present disclosure, the base chain is used to provide computing power for the application chain. As for whether digital currency can be issued on the base chain, it is optional. If digital currency is also issued on the base chain, the block body of the base chain block It can also record transactions and mining information. The mining information can be recorded in the first transaction of the block (also known as Coinbase), and its content includes the description of the block producer, mining rewards, etc. According to the transaction and mining information in the block body, the merkle tree can be organized, and the calculated merkle root is stored in the block header, which is recorded as merkle_root3. At this time, the base chain adopts a three-merkle tree structure. The content of the transaction is already available in the current blockchain system and will not be described in detail.

Before each base chain miner puts the received block into the local base chain ledger, the verification of the block content will be performed first. The content can include: verifying the first provable word in the candidate information of each proposal in the election basis Whether the string is forged (the method is as described above); According to the election process of repeating the leader of the proposal group according to the election basis, verify whether the selected leader is consistent with the record in the election result; other regular verifications on the content of the block (such as verification area Block header content, verifying whether the transaction is legal when the transaction is included in the block, etc.). If all the verification items are passed, the base chain miners will perform accounting.

The above describes the success of the election proposal group leader of the application chain to be mined block. In fact, it is also possible for the new height of the application chain to be mined block election to fail. In step S102, two possible reasons for failure are mentioned, neither Exclude other reasons for the election failure. If the leader of the election proposal group of the block to be mined of an application chain fails, the corresponding election results and election basis will not be recorded in the block generated this time on the base chain. If the base chain block adopts the election result list and election According to the form of the list, the entries in the two lists corresponding to the application chain are left blank. Of course, the election of the leader of the proposal group on each application chain is independent of each other, and the contents of other entries are not affected.

If the leader of the proposal group fails to be elected for the block at the new height of the application chain, a simple way is to postpone it until the next block generation of the base chain and try to elect the leader of the proposal group for the block of the new height of the application chain. Another more complicated approach is to first try to reselect the leader of the proposal group at a number of old heights before the new height of the application chain. If the attempt is successful at an old height, then re-dig the application chain block at the old height. , If all are unsuccessful, it will be postponed until the next block generation of the base chain to try to elect the leader of the proposal group for the new height of the application chain. The latter method is specifically introduced below:

If the base chain miner fails to elect the leader of the proposal group for the new height block based on the mining request in the new height waiting to be elected set, first determine that the application chain adjacent to the application chain to be mined block in the application chain has been selected The old height of the block of the leader of the proposal group, where the old height is lower than the new height in the application chain, and the above-mentioned adjacent meaning refers to adjacent in the sense of ignoring empty blocks in the application chain.

After determining the old height, the base chain miners select the mining request matching the old height from the cached mining requests and include them in the waiting set for the old height. The so-called matching refers to the block to be mined in the application chain in the mining request. The height item is consistent with the old height. Note that since the application chain block of the old height has successfully elected the leader of the proposal group, some of the mining requests for the application chain block of the old height initiated by the application chain miners have been successfully elected before. Time has already been used, and this part of the mining request will not be reused (otherwise, the result of reselecting the leader of the proposal group at the old altitude may not change), that is, the mining requests that match the old altitude collected by the base chain miners at this time are Refers to those mining requests that have not been used and targeted at the old height.

After that, the base chain miners re-elect the proposal group leader of the block of the application chain at the old height according to the mining request in the waiting set for the old height, the election method and the previous election of the proposal group of the block of the application chain at the new height The leaders are similar, so I won't elaborate on it. If the election is successful, the results of the election and the basis for the election will be saved in the base chain block. If the election fails, repeat the above process, that is, first determine the old height adjacent to the application chain height of the current election proposal group leader, and then perform the operations of collecting mining requests and electing the proposal group leader for the old height ( Referred to as re-mining old blocks, the corresponding operations for the leaders of the new height election proposal group can be referred to as mining new blocks), until one of the following two conditions is met, stop re-mining old blocks:

First, the leader of the proposal group was successfully elected for a block at an old height of the application chain. At this time, the election result and the basis of the election of the block of the old height are stored in the base chain block that was released this time. It is understandable that if the leader of the proposal group is successfully elected at an old height of the application chain, it may cause the block of the old height to be re-produced, and all the blocks connected after it in the application chain are also invalid and need to be re-mined. .

Second, re-dig old blocks to reach the preset limit of times. For example, taking the number limit of 3 as an example, assuming that the new height of the application chain is 100, if the leader of the proposal group of the new height block fails, during the current block generation period of the base chain, the base chain miners can be at most At the old heights 99, 98, and 97 of the application chain, try the above-mentioned re-digging of old blocks. If the leader of the proposal group cannot be successfully elected at the above three old heights, no further attempts will be made.

Finally, if the re-mining of old blocks is stopped due to the second reason above, the leader of the proposal group will be elected for the block of the application chain at a new height when the base chain is next produced. If the election still fails, then Try to re-dig the old block and repeat.

However, it should be noted that if the leader of the proposal group for the block generation election of the base chain is unsuccessful (regardless of whether it is at the new height or the old height), the mining request for the new height used in the block generation of the base chain is in the base chain. The next time the chain is produced, it will no longer be used to elect the leader of the proposal group of the block of the new height (but it can be used as a mining request for the old height to re-mine the old block), because the base chain Block production leads to changes in the base chain ledger, and the value of the first provable string in the mining request will also change (due to the change in the value of the first election string used to calculate the first provable string), mining The height of the base chain block that determines the leader of the proposal group in the mining request will also change, and the base chain miners need to reassemble new mining requests.

Correspondingly, the mining request for the old height used in the current block generation of the base chain can be reused in the next block generation of the base chain, because the operation of re-mining old blocks is not tied to the height of the base chain block. That is, after the leader of the block election proposal group with the old height of the application chain succeeds, the election result and election basis are directly recorded in the latest block of the base chain, instead of recording the specified height in the mining request for election ( Refers to the base chain block that determines the height of the base chain block of the leader of the proposal group in the mining request. The new block mining operation is tied to the height of the base chain block, that is, after the leader of the block election proposal group of the new height of the application chain is successful, the election result and election basis must be recorded in the specified height of the mining request for election (Refers to the base chain block height of the base chain block that determines the leader of the proposal group in the mining request).

For a mining request, the base chain miner can distinguish whether it is a mining request for a new height or a mining request for an old height based on the information of the height of the block to be mined in the application chain, and adopt different processing methods. . For the mining request for the old height, since the height of the base chain block to determine the leader of the proposal group has been specified in the mining request, the first election string at this time can be obtained according to this height (for example, take the first election string of the height). The information in the L block) is further used for the verification of the first provable string in the request. After the verification is passed, the mining request can be used for the election of the leader of the proposal group for the block of the old height. The reasons for the different processing methods for mining requests for mining new blocks and mining old blocks are:

In some implementations, application chain miners can verify the previous block in advance and issue a mining request for a new height in advance (see the following content for advance verification), so that the request has sufficient time to spread in the base chain, so Although the mining request for the new height is only valid during the block generation period of the base chain, the probability of selecting the leader of the proposal group for the block of the new height is also higher. However, the mining request for the old height may not be able to be fully disseminated (the ones that have been effectively disseminated, have been used before the leader of the proposal group at the old height, and cannot be reused), so it is allowed to publish multiple times on the base chain. During the block process, as many mining requests for the old height as possible (these requests may not have been propagated in time), plus if the old block is unsuccessfully re-mined, the mining request for the old height can be reused. Conducive to the successful re-election of the leader of the proposal group at the old height.

The following is a simple analysis of the reasons for allowing the re-mining of old blocks: the base chain is responsible for selecting the leader of the proposal group for the application chain, but it does not presuppose whether the selected proposal group leader can play a role in the application chain (playing a role means successfully If it does not play a role, as a remedy, it is permissible to overturn and re-dig the old block, and re-dig the old block is a specific measure to achieve the derivation and re-start. There are many reasons why the leader of the proposal group fails to play a role in the application chain: For example, the base chain believes that a certain height block of the application chain has selected the proposal group leader, but the proposal group leader’s block has not been selected. Pass the verification of the members of the verification group, or the verification report issued by the members of the verification group fails to pass the verification due to communication reasons that cannot be effectively transmitted (see the following content for the verification process), that is, the block is not approved by the application chain; For another example, although both the base chain and the application chain follow the longest chain rule, they are not completely synchronized, that is, the longest chain of the base chain does not necessarily correspond to the longest chain of the application chain, so the base chain follows the longest chain The rule switches to a new branch. The recently selected leader of the proposal group on the new branch may correspond to the block at the old height of the longest chain of the application chain (rather than the highest block), and may also be the longest block of the application chain. The chain has different leaders of the proposal group on the block of the old height; of course, it may also include other reasons, which will not be listed. In short, allowing the re-mining of old blocks in the application chain helps eliminate soft forks and exceptions in the application chain.

The above introduces the content of re-mining old blocks, but in the following description, we will still focus on the application chain blocks to be mined at new heights. For the old blocks generated by re-mining, the processing method is similar to the new block.

Step S104: The application chain miner synchronously determines the base chain block information of the base chain block of the proposal group leader of the block to be mined in the application chain from the base chain miner.

Application chain miners need to synchronize the base chain block information from the base chain miners in order to know the election results of the application chain to be mined blocks. The base chain block information comes from the base of the leader of the proposal group that determines the application chain to be mined. Chain block, the base chain block information includes at least the election result of the leader of the proposal group specifying the block to be mined in the application chain. According to what was mentioned in the description of Figure 1, in one implementation, the application chain miners directly synchronize related data from the base chain miners, and in another implementation mode, the application chain miners indirectly synchronize related data from the base chain miners. : Synchronization nodes can be set in the base chain, application chain miners can synchronize related data from the synchronization node, and the data of the synchronization node is synchronized from the base chain miners or other synchronization nodes, because the former implementation method can be regarded as the base chain miners. In order to achieve the function of the synchronization node, the following mainly introduces the specific implementation of the latter method.

Base chain block information can take at least one of the following three forms:

One is to use the base chain block itself of the leader of the proposal group that determines the block to be mined in the application chain. The synchronization node obtains the base chain block from the base chain miner (it can be a block verified by the base chain miner, of course, it does not rule out the verification of the synchronization node itself), and then the application chain miner obtains the base chain block from the synchronization node, and finally The base chain ledger is formed locally by the application chain miners (of course, simple verification can be done before the base chain block information is included in the ledger). The above-mentioned acquisition can be either an active request or a passive receiving method.

Second, use the block header of the base chain block and the election result list in the block body of the base chain block. The structure of the election result list has been introduced above. Each entry in the table corresponds to the election result of a block to be mined on an application chain, which also includes the election of the leader of the proposal group of the block to be mined on the application chain. result. Compared with the first form, considering that the election basis in the base chain block is not used by the application chain miners, it may not be included in the base chain block information to reduce data synchronization overhead.

In an optional scheme, the synchronization node obtains the block header and the election result list of the base chain block from the base chain miner or other synchronization nodes, and then the application chain miner obtains the area of the base chain block from the synchronization node. The block header and the election result list, and finally the base chain ledger is formed locally by the application chain miners (of course, the base chain block information can be simply verified before being included in the ledger), and the block header of the block in the base chain ledger is the same as the base chain block , The block body only contains the list of election results in the base chain block, which is a simplified base chain ledger.

Third, use the block header of the base chain block and the fragment data for the application chain in the block body of the base chain block. Among them, the fragment data includes the election result of the leader of the proposal group for the block to be mined in the application chain in the election result list, and the merkle root (that is, the merkle root calculated based on the election result list in the block header of the base chain block). The merkle path between merkle_root1) mentioned above. In the second form of base chain block information, the election result list still contains the election results in each application chain. However, for the application chain where the block to be mined in the application chain is located, other application chains other than itself You do not need to care about the election results on the above. Therefore, as long as the block header and the fragment data related to the application chain in the block body are retained in the base chain block information, this can further reduce the data synchronization overhead. In common applications In the scenario, one base chain can serve hundreds of application chains. If the third type of base chain block information is adopted, the amount of data transmission can be saved considerable. In the fragment data, the merkle path is composed of a series of hash values, which can be used to verify that the election result of the leader of the proposal group for the block to be mined in the application chain in the fragment data has not been forged. In the prior art, the merkle path can be used To verify whether a certain transaction has been forged, the verification principle here is similar and will not be elaborated.

In an optional scheme, the synchronization node obtains the block header and the election result list of the base chain block from the base chain miner or other synchronization nodes, and then the application chain miner obtains the area of the base chain block from the synchronization node. The block header and the fragment data for the application chain where the miner is located, and finally the base chain ledger is formed locally in the application chain miner (of course, the base chain block information can be simply verified before being included in the ledger), and the block header of the block in the base chain ledger Like the base chain block, the block body only contains fragments of data for the application chain, which is a further simplified base chain ledger.

Regardless of the form of the base chain block information, it contains the election result of the leader of the proposal group of the application chain to be mined. According to the previous article, the content of the election result includes the information sent from the leader of the proposal group for the application chain to be mined The proposal candidate information obtained in the mining request of the block includes at least the application chain identifier, the parallel chain chain number, the height of the block to be mined in the application chain, the height of the base chain block that determines the leader of the proposal group, and the application chain miner’s public The key and the first provable string of six pieces of information.

Furthermore, in some implementations, the election result can be further simplified to include only two pieces of information, the miner ID of the leader of the proposal group and the height of the block to be mined in the application chain. Among them, the miner ID of the leader of the proposal group is based on the application chain ID, the parallel chain number and the public key of the application chain miner in the mining request sent by the leader of the proposal group. The hash algorithm is used for calculation. The identity of the mentioned application chain miners is the same (because the leader of the proposal group originally belongs to the application chain miner); the height of the block to be mined in the application chain can be directly copied from the application chain waiting in the mining request sent by the proposal group leader The height of the mining block. For example, in a specific implementation, the miner identification of the leader of the proposal group is a 32-byte hash value, and the height of the block to be mined in the application chain is a 4-byte integer, and the two occupy 36 bytes in total. Assuming that the base chain serves 300 application chains, taking the second implementation of the base chain block information as an example, the election result list of 300 entries only occupies 10.8KB, plus the block header occupies about 11KB. Such a small amount of data is easy to synchronize with chain miners.

Not only does the election result when the base chain synchronizes the base chain block information with the synchronization node can adopt the above simplified form, when the synchronization node synchronizes data with the base chain miner or other synchronization nodes, the election result can also adopt the above simplified form. Even in the base chain block stored locally by the base chain miners, the items in the election result list (each item corresponds to an election result) can also adopt the above simplified form. It is understandable that the items in the election result list After adopting the simplified form of the election results, it has no other impact on the structure of the base chain block. The merkle root calculated based on the entries in the election result list is still stored in the block header. In the local base chain block of the base chain miners, since the election basis list saves the backup of the election results (the mining request corresponding to the election result must also be one of the mining requests based on the election), any one can be restored at any time The original form of the election results.

For the synchronization node in the base chain, data can be synchronized from the mining node in the base chain or other synchronization nodes, but the mining node in the base chain will not synchronize data from the synchronization node (because the mining node must ensure the integrity of the data , The simplified version of the data cannot be synchronized). After each node joins the base chain, it establishes a connection with other nodes and can inform each other of its own attributes (whether it is a mining node or a synchronization node), so that when the nodes synchronize data with each other, they will adopt different attributes according to each other’s attributes. operating.

As mentioned earlier, a query table can be built on the application chain or the base chain to query the number of times that the application chain miners have been elected leaders of the proposal group in a preset historical time period (corresponding to several base chain blocks), as the application chain miners Proposal group participation weight. A possible implementation of the form is given here. The form includes three fields: the miner ID of the leader of the proposal group, the height of the base chain block of the elected leader of the proposal group (here refers to the block in the base The actual height in the chain is not the height of the base chain specified in the mining request, because the existence of remining old blocks makes these two heights not necessarily the same) and the height of the block to be mined in the application chain. In the three fields, the last One field is optional. Indexes can be set on the first two fields to speed up the query.

Taking the application chain miner as an example, the table can be constructed based on the synchronized base chain block information. The base chain block information includes at least the election results of the application chain to be mined blocks. If the election result is in the original form (that is, it contains proposal candidate information), the value of the first field in the form can be calculated based on the application chain identifier, parallel chain chain number, and application chain miner public key in the proposal candidate information. The value of this field is directly copied from the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, and the third field is directly copied from the height of the application chain block to be mined in the proposal candidate information. If the election result is in a simplified form, the values of the first and third fields in the table can be directly copied from the election results, and because the application chain miners store the base chain ledger locally, according to the information in the base chain block Block header, the block formed by the block information of the base chain should be connected to which branch of the base chain which position is clear, and the value of the second field can also be determined.

Step S105: The application chain miners participate in the selection of the members of the verification group of the block to be mined in the application chain.

Step S106: If it is determined that the app chain miner is selected as a member of the verification group of the block to be mined in the app chain, the block produced by the leader of the proposal group is verified, the verification result is written into the inspection report and the inspection report is broadcast to other app chain miners .

The above two steps are combined and explained. Before explaining, first introduce the concept of full-staff verification. In the solution of the present disclosure, providing a new block (proposal link) and verifying a new block (verification link) are the two most critical links to ensure the security of the blockchain system. The adversary cannot directly control either of these two links. To achieve the purpose of cracking, both must be controlled. Of these two, the verification link is more important for security, because the organization of illegal block content is difficult to completely defend against attacks from a theoretical analysis. For example, if an adversary lurks an application chain miner, only when it learns that it has been elected as a miner The leader of the proposal group only acts evil when it comes to the proposal, and it is difficult to control it during the proposal process. But in the verification process, it can be controlled. The most stringent control is full-staff verification, that is, all application chain miners complete verification of any new block, and only after the verification is passed can it be included in the application chain ledger. However, the efficiency of full-member verification is low. Although in some existing blockchain systems (such as Bitcoin), full-member verification is restricted: only historical blocks (non-recently generated blocks) Simple verification, not complete verification, but full verification still has a great impact on the system TPS.

In the solution of the present disclosure, a compromise is considered between security and TPS, and a verification group is formed from all application chain miners for block verification. The verification group is a collection of application chain miners meeting preset rules. , Only the members of the verification team have the right to fully verify the new block and issue an inspection report. Other application chain miners simply collect the inspection report and make appropriate statistics based on the inspection report to reach the final verification conclusion (of course, the members of the verification team will also Collect inspection reports). The number of application chain miners in the verification group can only account for a small part of the total number of application chain miners, such as 1/10. In this way, without considering the communication bottleneck between nodes, the TPS of the blockchain system can also be approximately increased. 10 times.

Of course, this disclosure can also add the parameter of the full-member verification flag. This parameter can take at least two values (such as True and False), which respectively indicate that the full-member verification is adopted and the full-member verification is not adopted, and the full-member verification is not adopted. That is, to adopt the method of forming a verification group to verify. If the all-member verification mark indicates that all-member verification is adopted, each application chain miner will complete the verification of the block produced by the leader of the proposal group (the blockchain database is being rebuilt, except for miners who are in a state of catching up with the progress of the block). In the following text, we mainly introduce the method of establishing a verification group for verification.

For the application chain to be mined blocks that are being mined, the verification group refers to the collection of application chain miners who have the right to verify the blocks produced by the leader of the proposal group and generate inspection reports. The block produced by the leader of the proposal group is actually the application chain to be mined block packaged by the leader of the proposal group. However, according to different implementation methods of the application chain, there may be multiple application chain miners packing the application chain to be mined area for the same height of the application chain. Block, that is, multiple application chain blocks to be mined may be generated, so the name is slightly differentiated here.

The selection of the verification group members of the application chain to be mined blocks can be divided into at least one round. When the application chain miners synchronize to the base chain block information of the leader of the proposal group that determines the application chain to be mined blocks, they participate in the first P round The selection of verification group members. After that, the application chain miners will participate in a new round of selection of verification group members every time they synchronize with the information of a base chain block. If one of the following cycle termination conditions is met, the application chain miners will no longer participate in the new round of verification. Selection of group members:

First, the application chain miners have determined that they are selected as members of the verification team in the selection rounds they have participated in; second, the application chain miners can conclude that the block produced by the proposal group leader has passed the verification based on the currently received inspection report Third, the selection rounds that the miners of the application chain have participated in have reached the preset maximum round MaxRounds (MaxRounds is a positive integer).

Among them, 1≤P≤MaxRounds, if the application chain miner determines that he is elected as a member of the verification group in the selection rounds he has participated in, he will verify the block produced by the leader of the proposal group and broadcast the generated result to other application chain miners. Inspection report (that is, step S106 is executed). If P=1, it means that application chain miners cannot participate in the selection of verification group members in subsequent rounds in advance, and if P>1, it means that application chain miners can participate in the selection of verification group members in subsequent rounds in advance. The following first introduces the case of P=1:

The selection of members of the verification group can be regarded as driven by the block generation of the base chain. Each block of the base chain (application chain miners will also correspond to the synchronization of the base chain block information) will carry out a round of verification group member selection, and each round of verification group In the selection of members, several verification group members may be selected. If multiple rounds of selection are carried out, the verification group members selected in each round are superimposed, that is, as the round grows, there will be more and more members in the verification group. Application chain miners who are selected as members of the verification group in a certain round do not need to participate in the selection of verification group members in subsequent rounds (the above cycle termination condition 1), and the identity of the verification group members can always be retained.

Once selected as a member of the verification group, the application chain miners will verify the block produced by the leader of the proposal group, issue an inspection report and broadcast it in the application chain. Each verification group member will only generate one inspection report. The reporting process will be explained later. While participating in the selection of members of the verification team, the application chain miners are also receiving inspection reports sent by the members of the verification team. If the block verification by the leader of the proposal group can be confirmed based on the collected inspection reports, they do not need to continue to participate in the election. Verify the members of the group (the above loop termination condition two). For example, currently entering the third round of verification group member selection, an AppChain miner who has not been selected as a member of the verification group can judge the proposal based on the inspection report issued by the AppChain miner selected as a member of the verification group in the previous two rounds of selection. Whether the block produced by the group leader has been verified.

There are restrictions on the number of rounds for selecting members of the verification group, and the maximum number of rounds cannot exceed the preset maximum round (the above cycle termination condition 3). If it exceeds, the current application chain miners will end the selection of the verification group members of the application chain to be mined.

Allowing to be divided into multiple rounds of selection of members of the verification group is conducive to adaptively eliminating soft forks in the base chain and the application chain. The specific principles are explained later.

In the selection process of any round of verification group members of the block to be mined in the application chain, each application chain miner independently determines whether to be a member of the verification group according to a preset algorithm, and does not depend on other application chain miners. In a typical In the implementation manner, the above-mentioned preset algorithm can use the verifiable random function VRF algorithm, which has been introduced in the previous section when introducing the selection of the proposal group members.

Application chain miners first call the proof function in the VRF algorithm to obtain the second provable word based on their own private key (corresponding to the PrivateKey in the VRF algorithm) and the second election string determined by the preset rules (corresponding to the info in the VRF algorithm) String (corresponding to the proof in the VRF algorithm). After that, the application chain miner derives the third random value using preset rules based on the second provable string, and determines whether the application chain miner is selected as the verification group member of the application chain to be mined according to the third random value. Suppose the derivation rules are deterministic (but the specific rules are not limited), so for the same input, the derived third random value is also deterministic, and then the verification group members obtained on the basis of the third random value The results of the election are also deterministic.

The above-mentioned second election string is a known string, and its acquisition rule is determined. In one implementation, the second election string is calculated based on the following information: the miner ID of the leader of the proposal group, the height of the base chain block that determines the leader of the proposal group (here refers to the actual height of the block in the base chain Rather than the base chain height specified in the mining request, the two heights are not necessarily the same due to the existence of the re-mining of the old block), the height of the block to be mined in the application chain, and the round number of the selection verification group member. If the election result for the block to be mined in the application chain in the base chain block information is in the original form (that is, it contains proposal candidate information), it will be based on the application chain identification, parallel chain chain number, and application chain miner public key in the election result. Information calculates the first item of information, plus the second and third items of information obtained from the election results, and calculates the second election string in combination with the round numbers of the members of the current selection verification group; if the election result is in a simplified form, then The first and third items of information are obtained from the election results. The second item of information is the height of the base chain block storing the election results, and the second election string is calculated in combination with the round numbers of the members of the current selection verification group. The rounds for selecting verification group members can be numbered starting from 0 and increasing in the order of natural numbers. When application chain miners participate in different rounds of verification group member selection, the value of the number will also change accordingly.

In some implementations, it may be directly determined according to the third random value whether the application chain miner is a member of the proposal group of the block to be mined in the application chain. In other implementations, each application chain miner can calculate its own verification group participation weight, and each application chain miner can determine whether he is an application chain based on the third random value and its own verification group participation weight. The members of the verification group of the block to be mined. Among them, the probability of the application chain miner being selected as a member of the verification group is positively related to the value of the weight of the verification group.

For example, the verification group participation weight of an application chain miner can be calculated based on the amount of digital currency currently held by the miner (provided that digital currency is to be issued on the application chain), and it is stipulated that if the application chain miner does not currently hold digital currency Currency, the verification group participation weight is 0. Under this regulation, a typical implementation method is: application chain miners' verification group participation weight priority2 is proportional to their currency stake, namely:

priority2=C×stake

Where C is a normal number. Of course, the relationship between priority2 and stake can also be other relationships if the foregoing requirements are met. In this implementation method, the application chain miners who hold more coins have a higher weight for the verification group to participate in the election, so the probability of being selected as a member of the verification group is also higher, because the more coins they hold, the more the miner and the application The closer the chain of interest is, the less likely it is to cheat.

In some implementations, the minimum currency holding parameter can also be preset on the application chain. If the current number of digital currencies held by the application chain miners is less than the preset minimum currency holdings, the application chain miners cannot participate in the verification group members Selection. Typically, application chain miners who do not hold digital currencies cannot participate in the selection of members of the proposal group. This can prevent the sybil attack of forging a large number of new accounts to participate in mining. Of course, in some alternative solutions, the minimum value of the preset verification group participation weight can also have a similar effect.

In some implementations, the application chain can also preset the parameter of the verification group’s maximum participation weight, that is, set an upper limit for the verification group’s participation weight. If the calculated verification group’s participation weight exceeds the upper limit (for example, the application Because chain miners hold a large amount of digital currency, the verification group participation weight is greater than the preset verification group maximum participation weight), then the verification group participation weight is set to the verification group maximum participation weight. Avoid a large number of application chain miners holding coins in the selection of members of the verification group to have too much advantage, depriving other application chain miners of the opportunity to be elected members of the verification group.

Of course, other definitions can also be used for the weight of the verification group participation, but it is more convenient to calculate based on the number of coins held by the application chain, because the application chain ledger records the unspent transaction output (UTXO) of all accounts in the chain. , So that all application chain miners can check the amount of coins held by others and calculate the corresponding verification group participation weight, and then can verify whether others are eligible to be elected members of the verification group.

Application chain miners determine whether they are members of the verification group of the application chain block to be mined according to the third random value and their own verification group participation weights. There are also different implementation methods. In one implementation method, it can be implemented as follows:

First, use the following formula to calculate the fourth random value RandValue4:

RandValue4=(RandValue3%ExpectedRange2)+priority2

Among them, RandValue3 is the third random value, ExpectedRange2 is the preset range value, priority2 is the weight of the verification group participation, and% represents the remainder operation.

If the calculated RandValue4 satisfies the following conditions, it is determined that the current application chain miner is selected as the proposal group member of the application chain to be mined block:

RandValue4>ExpectedRange2-(ExpectedRange2*1/M2)

Among them, M2 is the preset filtering ratio.

It is not difficult to see that the calculation formulas of RandValue4 and RandValue2 are basically the same, except that the preset parameter ExpectedRange2 can take different values from ExpectedRange1, and M2 can take different values from M1.

It can also be seen that the selection process of verification group members is similar to the selection of proposal group members, and the basis for election is recorded in the base chain block (because only proposal group members will send mining requests, it is equivalent to recording Proposal group members), so it is not ruled out that in some implementations, all proposal group members are directly used as verification group members, and the step of selecting verification group members is skipped. However, in the above scheme, the selection of verification group members and the selection of proposal group members are implemented as independent of each other (that is, whether an application chain miner is a member of the verification group and whether it is a member of the proposal group has nothing to do with the following aspects:

First, each application chain miner independently confirms whether he is a member of the verification group, which is more secure than the centralized confirmation of verification group members (referring to directly confirming the proposal group members as members of the verification group in batches); second, The selection of members of the verification group mentioned above can be divided into multiple rounds, which provides an adaptive mechanism to eliminate soft forks (see below); third, the members of the proposal group are listed in the base chain block election basis list for prevention The adversary's cheating allows all base chain miners to perform verification, not for the convenience of electing members of the verification group.

If an application chain miner confirms that he is a member of the verification group of the application chain to be mined in a certain round of selection, he can verify the block produced by the leader of the proposal group of the application chain to be mined. In different implementations, the timing of the proposal group leader to package the application chain to be mined may be different: for example, in the first method, any application chain miner will pack it after confirming that he is elected as a member of the proposal group The application chain to be mined blocks, but in the end only the application chain to be mined blocks packaged by the leader of the proposal group will be spread in the application chain and will be booked after verification. The application chain miners can synchronize the base chain block information. Knowing which application chain miner was selected as the leader of the proposal group, combined with the block producer information can determine which is the block produced by the proposal group leader; in the second method, only the proposal group leader will package the application chain The block to be mined, and the application chain miner can know whether he is the leader of the proposal group after synchronizing the information of the base chain block.

Optionally, for the first method, after the members of the proposal group have packaged the application chain to be mined blocks, they can also broadcast the application chain to be mined blocks to other application chain miners in a local area around it. The local scope here can be defined as the local scope in the sense of message forwarding. For example, the members of the proposal group specify a preset number of forwarding times in the broadcast message of the block to be mined in the application chain, and the block to be mined in the application chain passes every time For forwarding, the number of forwarding in the broadcast message is reduced by 1, and the block to be mined in the application chain will be stopped when the number of forwarding is reduced to 0. Of course, it is not ruled out that the local scope adopts other definition methods, such as the scope in the geographical sense, the scope in the network topology sense, and so on.

Local diffusion of the blocks to be mined in the application chain in advance (before the leader of the proposal group is determined) is beneficial to improve the security of the blockchain system. The specific analysis is as follows:

First define the concept of directional corrosion: directional corrosion refers to a certain malicious behavior of an adversary against a certain or certain specific application chain miners. For example, a network attack (such as a distributed denial of service DDoS attack) on a mining node where an application chain miner is located causes it to fail to work normally due to message congestion and other reasons, so that the application chain miner cannot produce blocks normally, which is beneficial to the adversary's further progress. Cracking behavior; another example, bribing an application chain miner, instructing them to keep accounts according to their own requirements, etc.

In the common implementation of the disclosed scheme, the base chain uses a public chain, has a large number of miners, and combines the block chain data of the base chain to determine how the members of the proposal group are selected (for details, please refer to the method of obtaining the first election string in the previous section) ), that is, combined with the computing power factor of the base chain, it is difficult for the adversary to control the value of the first election string according to their expectations, so that they cannot select specific application chain miners as members of the proposal group according to their wishes. Moreover, even if the adversary can learn the first election string at a certain time before the block is produced, because the application chain miner needs to combine his own private key in addition to the first election string when deriving the first provable string, Therefore, the adversary cannot derive the first provable string based on the first election string alone, and thus cannot derive the first random value or the second random value that is the basis for the application chain miners to be elected members of the proposal group, and it is difficult to determine an application in advance. Will chain miners be elected as members of the proposal group so that they cannot be directionally corroded?

However, once a member of the proposal group sends a mining request to the base chain miner, the membership of the proposal group will be exposed (for example, the adversary can deploy a specific application to listen to the mining request, or deploy a dedicated miner of his own on the base chain. Receive the request), so that the adversary can directionally corrode the members of the proposal group.

In order to solve this problem, after determining that they are members of the proposal group, miners of the application chain are required to immediately package the block to be mined in the application chain and spread the block in a limited range (the reason is limited to a partial range, mainly to avoid excessive consumption. Multiple bandwidth resources). Due to the advance diffusion, each application chain miner may receive multiple application chain blocks to be mined at the same height, which are packaged and produced by different proposal group members, but the application chain miners can determine after synchronizing the base chain block information The leader of the proposal group, the application chain miner will only keep the application chain to-be-mined block packaged by the proposal group leader (if the application chain miner has cached the block locally) and broadcast the block to other application chain miners (this time is Full chain broadcast), discarding the application chain to be mined blocks packaged by others.

In this way, even if the adversary learns his identity when the members of the proposal group request mining, because the application chain to be mined blocks have already spread in the application chain, directional corrosion will not be effective. For example, even if the adversary determines the leader of the proposal group in some way, and launches a DDoS attack on the mining node where the leader of the proposal group is located, although the node may be paralyzed, the application chain miners in its surrounding area can still spread all of them. If you leave the block, it will not be affected; for the same reason, bribing the leader of the proposal group is futile.

When the leader of the proposal group broadcasts the block, it also attaches the proposal candidate information in the mining request sent by the leader of the proposal group to the block in the broadcast message for block verification, and the follow-up proposal group leader issues When the block is spread in the application chain, the proposal information is always attached. Application chain miners who are selected as members of the verification group of the application chain to be mined block verify the block produced by the leader of the proposal group, including at least the following verification items:

First, according to the height of the base chain block that determines the leader of the proposal group in the above proposal candidate information, determine the first election string that the proposal group leader relies on when he is elected as a member of the proposal group. Then, call the verification function in the VRF algorithm based on the first provable string in the proposal candidate information, the application chain miner's public key in the proposal candidate information, and the first election string to verify the first provable word in the proposal candidate information Whether the string is forged, if it is not forged, the verification of this item is passed, if it is forged, the verification of this item is not passed. The verification content of this item can refer to the verification process of the first provable string in the mining request by the base chain miners, which has been explained above.

Second, verify whether the application chain miner corresponding to the application chain miner's public key in the proposal candidate information is the creator of the block produced by the leader of the proposal group. In the solution of the present disclosure, a certain mechanism can be designed to specify the creator of the application chain block:

For example, the public key information that characterizes the identity of the block creator is stored in the block header (for example, it can be the public key itself, the hash value of the public key, etc.), and the verification group members apply the chain miner public key in the proposal candidate information The corresponding public key information can also be obtained, and the two can be compared. If they are consistent, it can be confirmed that the application chain miner corresponding to the application chain miner’s public key in the proposal candidate information is the creator of the block produced by the leader of the proposal group. If the verification is passed, otherwise it can be confirmed that the miner of the application chain is not the creator of the block produced by the leader of the proposal group, and the verification is not passed.

For another example, as mentioned above, when the leader of the proposal group broadcasts the block, the corresponding proposal candidate information is attached to the broadcast message. In addition, it can also be accompanied by a proposal group leader who uses his own private key to pair the outgoing area. The signature of the block (for example, it can be the signature of the entire block, it can be the signature of the block header, it can be the signature of some fields in the block header, etc.). The members of the verification group use the public key of the application chain miner in the proposal candidate information to verify whether the signature of the block produced by the leader of the proposal group carried in the broadcast message is correct. If it is correct, the public key of the application chain miner in the proposal candidate information can be confirmed The corresponding application chain miner is the creator of the block produced by the leader of the proposal group, and this verification is passed, otherwise it can be confirmed that the application chain miner is not the creator of the block produced by the leader of the proposal group, and this verification fails.

In addition, the above implementation of storing the public key information of the block creator in the block header does not exclude the replacement of the public key information with the creator's miner identification, and the proposal candidate information can also be used to calculate a miner identification for verification.

Third, according to the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, the leader of the proposal group is queried from the local base chain ledger of the verification group member (of course, it is used to query the proposal group as mentioned above. It is also possible to inquire in the table of the number of leader elections), and then verify whether the inquired leader of the proposal group is consistent with the leader of the proposal group determined by the proposal candidate information.

The identity of the leader of the proposal group can be represented by a public key or a miner ID. For those represented by public keys, this verification is implemented as follows:

First, according to the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, query the public key of the proposal group leader from the local base chain ledger (at this time, the election results in the base chain ledger are in the original form), and then Verify that the public key of the queried proposal group leader is consistent with the public key of the application chain miner in the proposal candidate information. If they are the same, confirm that the queried proposal group leader is consistent with the proposal group leader determined by the proposal candidate information. The verification is passed, otherwise it is confirmed that the leaders of the two proposal groups are inconsistent, and the verification fails.

For those represented by the miner's logo, this verification is implemented as follows:

First, according to the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, query the miner ID of the proposal group leader from the local base chain ledger (at this time, the election results in the base chain ledger are in a simplified form), and then Based on the application chain miner’s public key, application chain ID, and parallel chain chain number in the proposal candidate information, the hash algorithm is used to calculate the miner ID of the leader of the proposal group, and finally the miner ID of the queried proposal group leader is verified. Whether the miner IDs of the calculated proposal group leaders are the same, if they are the same, confirm that the queried proposal group leader is consistent with the proposal group leader determined by the proposal candidate information, this item is verified, otherwise the two proposal group leaders are confirmed Inconsistent, this verification failed.

Fourth, verify whether all transactions in the block produced by the leader of the proposal group are correct. If they are correct, the verification is passed, otherwise the verification fails. The specific verification content includes verifying whether there is a forged transaction, implementing double spending, etc. This verification is similar to the verification of transactions in the existing blockchain system, and will not be specifically explained.

Further, after the first verification is passed (note that there is no inevitable sequence for the verification above, the first verification may not be the first to pass), the first verification can be derived from the first provable string in the proposal candidate information. Random value, and then calculate the second random value based on the first random value and the proposal group leader’s participation weight of the proposal group determined by the proposal candidate information (see the previous section for the specific formula), and finally verify whether the second random value is consistent with the elected proposal group leader People’s basic requirements, for example, whether they meet the minimum random value requirement, if they are met, the verification of this item is passed, otherwise the verification of this item is not passed. When I first introduced the composition of the proposal candidate information, it was mentioned that in some implementations, the proposal candidate information can also include the second random value that the miners of the application chain rely on when they are selected as members of the proposal group. For these implementations, in derivation After the second random value is obtained, it is also possible to verify whether the derived second random value is the same as the second random value in the proposal candidate information.

If the verification results of all the above verification items are passed, the verification team members generate the inspection report that the inspection conclusion is passed. Otherwise, the verification team members generate the inspection report that the inspection report is not passed. After the verification team members generate the inspection report, they are in the application chain Broadcast the inspection report.

From the above selection process of verification group members, it can be seen that when application chain miners participate in the selection of each round of verification group members for the block to be mined in the application chain, the third random value or the fourth random value or fourth value calculated as the basis for the election is caused. The reason for the different random values is that the round numbers of the members of the selection verification group used in the calculation of the second election string are one item, and the remaining items can be regarded as fixed values during the selection period. Therefore, only in principle, the application chain miners participating in the selection of members of the verification group are not restricted by the synchronization base chain block information. The application chain miners only need to adjust the round number value by themselves to determine that they are in a certain round. Whether the selection of will be selected as a member of the verification group, even if the base chain block information originally used to indicate the start of this round of selection has not been synchronized, it is referred to as early verification for short, which corresponds to the situation of P>1 mentioned above.

For example, P=3, when the application chain miner synchronizes to the base chain block information of the leader of the proposal group that determines the block to be mined in the application chain (assuming it corresponds to a block with a height of H on the base chain), they can participate in the first Round (the round number is 0), the second round, and the third round of the selection of members of the verification group (of course, if you confirm that you are a member of the verification group in the first round, you don’t have to participate in the subsequent rounds of selection), no need to wait for the original Used to indicate the start of the second and third rounds of the base chain block information selected by the members of the verification group (the base chain block information corresponding to the base chain block at the height of H+1, H+2). If you do not participate in advance, At this time, it can only participate in the first round of selection of members of the verification group; when the application chain miners synchronize to the base chain block information corresponding to the base chain block with a height of H+1, they can participate in the fourth round of verification group members. If it does not participate in the election in advance, it can only participate in the second round of selection of members of the verification team; and so on.

Once the application chain miner has determined that he is a member of the verification group in a certain round of selection, he will verify the block produced by the leader of the proposal group and broadcast the inspection report. Compared with the case of P=1, the inspection report here can be regarded as advance Broadcast out. Broadcasting the inspection report in advance is conducive to the full dissemination of mining requests on the base chain, and the specific reasons will be analyzed in step S107.

The above describes the implementation method of additionally carrying block verification information in the broadcast message sent by the leader of the proposal group. In addition to the proposal candidate information, the block verification information can also include the proposal group participation weight, the first random value, and the first random value. 2. Information such as random values. In addition, in other implementations, the members of the proposal group can also save evidence that they are elected as members of the proposal group in the first transaction of the block (also known as Coinbase) when packaging the block to be mined in the application chain, for example, The information items in the proposal candidate information, the proposal group participation weight, the first random value, the second random value, etc., are used as block verification information for others to verify in the future. If a member of the proposal group is finally selected as the leader, the packaged block will be broadcast, and the information in Coinbase will naturally be spread along with the block. The effect is similar to that of sending the information separately.

Step S107: The application chain miner receives the inspection report, and judges whether the block produced by the leader of the proposal group is verified according to the inspection report.

Step S108: If the application chain miner determines that the block produced by the leader of the proposal group is verified, the block is included in the application chain ledger.

The above two steps are combined together to explain. In one implementation, the inspection report may include the following information items: the miner identification of the leader of the proposal group, the height of the base chain block that determines the leader of the proposal group, the height of the block to be mined in the application chain, and the selection of the members of the verification group The round number, the public key of the verification group member who generated the inspection report, the second provable string that the app chain miner relied on when they were elected as the verification group member, the hash value of the block to be mined in the app chain, the verification conclusion, and the use verification The private key of the group member signs the inspection report.

Among them, the first four items are used by application chain miners to calculate the second election string when participating in the selection of verification group members, and are attached to the inspection report for others to verify. The round number of the selection verification group member is the final confirmation of the application chain miners. It is the number of the selection round of the members of the verification group; the hash value of the block to be mined in the application chain is used to uniquely identify an application chain block, and the application chain miner can use the hash value when statistically verifying the conclusion of the report in step S107 Distinguish the reports for different application chain blocks; the inspection conclusions are the two conclusions of passing and failing, as described above; using the private key of the verification team member to sign the inspection report can refer to the inspection report except the signature itself The signature of other information is used to prevent the inspection report from being tampered with.

Before the application chain miners use the inspection report, they can verify the content of the inspection report. The verification items can include:

First, use the public key of the verification team member who generated the inspection report in the inspection report to verify whether the signature in the report is correct. If it is correct, the verification of this item is passed, otherwise the verification of this item is not passed.

Second, first query the leader of the proposal group from the local basic chain ledger according to the height of the base chain block that determines the leader of the proposal group in the inspection report (of course, it is used to query the number of elections of the proposal group leader as mentioned above) It is also possible to inquire in the form), and then verify whether the inquired leader of the proposal group is consistent with the leader of the proposal group identified in the inspection report.

In the local base chain ledger of the application chain, if the election result is in the original form (that is, it contains proposal candidate information), this verification is implemented as follows:

Firstly, query the public key of the proposal group leader from the local base chain ledger according to the height of the base chain block of the leader of the proposal group in the inspection report, and then obtain the application chain identification and parallel chain chain where the miner of the application chain is mining. (These two contents can be obtained by each application chain miner), based on these three pieces of information, the hash algorithm is used to calculate the miner ID of the proposal group leader, and then the calculated miner ID and inspection report of the proposal group leader are verified Whether the miner identifications of the proposal group leaders in are the same. If they are the same, confirm that the inquired proposal group leader is consistent with the proposal group leader determined in the inspection report. This verification is passed, otherwise it is confirmed that the two proposal group leaders are inconsistent. This verification failed.

In the local base chain ledger of the application chain, if the election result is in a simplified form, this verification is implemented as follows:

First, according to the height of the base chain block that determines the leader of the proposal group in the inspection report, query the miner ID of the proposal group leader from the local base chain ledger, and then verify the miner ID of the proposed group leader and the inspection report. If the miners’ identifications of the leaders of the proposal group are the same, confirm that the queried leader of the proposal group is consistent with the leader of the proposal group determined in the inspection report. This item is verified. Otherwise, it is confirmed that the leaders of the two proposal groups are inconsistent. Item verification failed.

Third, according to the identification of the miner of the leader of the proposal group in the inspection report, the height of the base chain block of the leader of the proposal group, the height of the block to be mined in the application chain, and the round number of the members of the verification group are selected based on the four pieces of information. Calculate the second election string that the application chain miners who generated the inspection report are selected as members of the verification group rely on, and then based on the second election string, the public key of the verification group member who generated the inspection report in the inspection report, and the verification report The second provable character string calls the verification function in the VRF algorithm to verify whether the second provable character string in the inspection report is forged. If it is not forged, the verification of this item is passed, otherwise the verification of this item is not passed.

Fourth, derive the third random value based on the second provable string in the inspection report, and verify whether the application chain miner who generated the inspection report is a member of the verification group based on the third random value. If it is a member of the verification group, the verification is passed. , Otherwise this verification fails. This verification is to repeat the selection of members of the verification team to determine whether the miners of the application chain are indeed qualified to issue an inspection report.

In one implementation, the application chain miner can first derive the third random value, and then calculate the fourth random value based on the third random value and its own verification group participation weight (see above for the specific formula), and finally based on the fourth random value Verify whether the miner of the application chain who generated the inspection report is a member of the verification team.

If the verification results of all the above verification items are passed, the application chain miner shall recognize the validity of the inspection report and perform the following steps. Otherwise, the inspection report is deemed invalid and can be discarded.

The application chain miners collect the received inspection reports for the blocks produced by the leader of the proposal group to perform statistics and obtain the verification results, which can be implemented as follows:

If the inspection conclusion in the received inspection report is that the number of reports that pass is not less than the minimum number of successful verifications, and the number of reports that the inspection conclusion is that the number of failed verifications is not greater than the maximum number of failed verifications, the block produced by the leader of the proposal group is determined Verification passed.

If in the received inspection report, the number of reports that passed the inspection conclusion is less than the minimum number of successful verifications, and the number of reports that the inspection conclusion is not passed is not greater than the maximum number of failed verifications, continue to wait for a new inspection report, unless waiting After a preset period of time (this period will be explained later), if the verification conclusion is that the number of reports passed is still less than the minimum number of successful verifications, it is determined that the block verification by the leader of the proposal group has not passed.

If in the received inspection report, the number of reports whose inspection conclusions are not passed is greater than the maximum number of failed verifications, it is determined that the block verification by the leader of the proposal group has not passed.

Among them, the minimum number of successful verifications and the maximum number of failed verifications may be preset values, or may also be calculated based on the number of application chain miners selected as the leader of the proposal group in a preset time period combined with a certain ratio. The minimum number of successful verifications represents the degree of recognition of the block by the members of the verification group, and the maximum number of failed verifications represents a tolerance range. It is also possible to set the maximum number of failed verifications to 0, but setting it to a non-zero value is mainly to prevent a small number of verification group members Evil (intentionally issuing a report that the inspection conclusion is not passed) causes the application chain to fail to produce blocks normally.

Application chain miners can judge whether they can draw a verification conclusion according to the above rules every time they receive an inspection report, or application chain miners can cache the received inspection reports first and make judgments at appropriate times (for example, regular judgments) . For the received inspection reports, application chain miners can prioritize the inspection reports of the earlier rounds according to the round numbers of the members of the selected verification group, so as to prevent the adversary from broadcasting the reports of later rounds in advance and affecting the verification results.

If the application chain miners determine that the block produced by the leader of the proposal group is verified according to the inspection report, the block will be included in the application chain ledger, and the selection of proposal group members for the next application chain to be mined can be started. If the application chain miner determines that the block produced by the leader of the proposal group fails to pass the verification according to the inspection report, the block produced by the leader of the proposal group will be discarded. If the block has been included in the application chain ledger and other blocks have been connected later They are discarded together, and the selection of members of the proposal group for the block to be mined in the application chain is restarted. Among them, the block after the block produced by the leader of the abandonment proposal group corresponds to the situation where the conclusion of the verification is overturned, which will be explained in detail later.

The application chain miner statistical inspection report can be regarded as a statistical voting process, and the voters are members of the verification group. A more general description of the process is as follows:

Application chain miners first determine the number of votes in the verification process of the received inspection report, and then make a judgment: if the inspection conclusion in the received inspection report is that the total number of votes in the report is not less than the minimum number of successful verifications, and , The total number of votes in the report whose inspection conclusion is that the failure is not greater than the maximum number of failed verifications, then the block verification by the leader of the proposal group is determined to be passed. Of course, there are still cases that need to wait and fail, which are similar to the above, and are omitted here.

In the most common situation, one inspection report can correspond to one vote, as described above. However, in other implementations, the number of votes occupied by each inspection report can be set to be positively correlated with the amount of digital currency currently held by the verification group member that generated the inspection report. The reason why the inspection report issued by the members of the verification team with more currency has a certain advantage is that the more members of the proposal team who hold the currency are more closely related to the interests of the application chain, the less likely it is to cheat.

Optionally, the number of votes occupied by the inspection report during the verification process can be calculated using the following formula:

vote_num=1+stake/leverage

Among them, vote_num is the number of votes occupied by the inspection report, stake is the number of digital currencies currently held by the members of the verification group that generated the inspection report, and the currency holdings are recorded in the application chain ledger, which can be queried by any application chain miner, and leverage is The preset vote adjustment ratio.

For the sake of simplicity, in the following explanation, the method of one inspection report for one vote is used as an example. If the number of copies of the inspection report is not consistent with the number of votes, the relevant content can be adjusted adaptively.

For a block at a certain height of the application chain, the application chain miners cannot accurately conclude whether the block will pass the verification before receiving enough inspection reports for the block, which leads to a verification conclusion It may take a long time. In an optional scheme, if the application chain miner finds that in the received inspection report, the proportion of the number of reports that the inspection conclusion is passed to the minimum number of successful verifications is no less than the preset verified proportion (of course, it must also meet The inspection conclusion is that the number of failed reports is not greater than the maximum number of failed verifications), then the selection of the proposal group members of the block to be mined in the next application chain and the packaging of the block will be started in advance. Among them, the verified ratio can be 50%, 60%, and so on. In most cases, the verification conclusion of the application chain block is passed, so the proposal group members selected in advance are reliable in most cases, and the probability of subsequent withdrawal of the membership of the proposal group is not high. The above-mentioned measures are conducive to improving verification and verification. The parallelism of the proposal work further enhances the TPS of the blockchain system.

In the previous description of steps S105 and S106, the implementation of advance verification was mentioned (P>1). The members of the verification group can verify the block produced by the leader of the proposal group in advance and broadcast the inspection report. Each application chain miner will check according to these inspections. The report may know the verification result of the block several rounds in advance. If the verification conclusion is passed, the application chain miners can determine at which height the application chain should mine next time, so that they can participate in the proposal of the next application chain to be mined in advance. The selection of the group members, and then send the mining request for the next application chain to be mined block to the base chain miners in advance, so the mining request has more time to spread in the base chain, which is conducive to the base chain miners to select the proposal group leader.

However, it should be noted that although the application chain miners can receive the inspection report in advance, and can draw the conclusion that the block verification by the leader of the proposal group has passed based on these inspection reports, they still have to wait for the inspection report to take effect before it can be executed. Include the block in the application chain ledger, and participate in the selection of the members of the proposal group for the next application chain to be mined. Among them, the inspection report takes effect after the application chain miners synchronize to the base chain block information corresponding to the report generation round, and the report generation round refers to the selection round in which the application chain miners who generated the inspection report are elected as members of the verification group.

For example, application chain miners received in advance the inspection report sent by the application chain miners selected as members of the verification group in the second round of verification group members, and based on the report, it can be determined that the block verification by the leader of the proposal group has passed. The subsequent steps cannot be executed immediately, and it is necessary to wait for the application chain miners to synchronize to the base chain block information originally used to indicate the start of the second round of verification group member selection. However, once it is time to synchronize to the base chain block information, the application chain miner can immediately give a conclusion that the block verification by the leader of the proposal group has passed, so there is still an advance in time, at most one base chain can be produced in advance. time.

Therefore, the so-called advance verification essentially only improves the degree of parallelization between the verification group member selection and subsequent steps, and does not destroy the synchronization relationship between the base chain block generation and the verification group member selection.

After adopting the early verification mechanism, although the application chain miners may be informed of the verification conclusion of the block produced by the leader of the proposal group in advance, they have time to cheat, such as changing the height of the block to be mined in the application chain, but because of the blockchain The consensus mechanism requires the approval of multiple miners to confirm the result. Therefore, even if the individual application chain mining is cheating, other honest miners do not collude with it, and the cheating behavior is futile: for example, individual dishonest miners change the height of the application chain to be mined, and Most honest miners do not carry out the next round of mining at this height, and the cheating behavior of dishonest miners ultimately fails due to insufficient votes.

As mentioned above, during the verification phase of the block produced by the leader of the proposal group, the application chain miners wait at most for a preset time. If the inspection conclusion received during this period is that the number of reports passed is always less than the minimum number of successful verifications (Of course, if the number of failed verification reports received during this period is greater than the maximum number of failed verifications, the waiting process ends early), it can be determined that the block verification by the leader of the proposal group has failed.

In one implementation, the above-mentioned preset duration is MaxRounds+Q base chain block generation time (Q takes 0 or a positive integer). For application chain miners, it is synchronized twice to the base chain block information. The interval is the block time of a base chain. The preset duration starts from the synchronization of the application chain miners to the base chain block information of the leader of the proposal group that determines the block to be mined in the application chain (this time is also the starting time for the first round of verification group member selection). MaxRounds base chain block generation time allows application chain miners to participate in the selection of verification group members (up to MaxRounds round selection) and broadcast the generated inspection report after confirming that they are selected, and apply chain miners within the next Q base chain block generation time Although you can no longer participate in the selection of members of the verification team, you can continue to receive inspection reports and determine whether the block produced by the leader of the proposal team has been verified based on the statistical results of the inspection reports. Of course, if an application chain miner is selected as a member of the verification team before the MaxRounds round of selection, it will take longer to receive the inspection report.

What is important is that for an application chain miner, even if it has confirmed that the block has been verified according to the inspection report for the block produced by the leader of the proposal group, it must continue to receive the inspection report until it reaches MaxRounds+Q The block generation time of each base chain. During this period, according to the newly received inspection report, the conclusion of the block verification passed by the leader of the proposal group may be overturned, because if the inspection conclusion in the newly received inspection report is not passed , The report score that may cause the inspection conclusion to be failed is greater than the maximum number of failed verifications. At this time, the block produced by the leader of the proposal group will be discarded, and because the block has been recognized as verified before, the mining of the subsequent high-level application chain block has been started, and even the follow-up area The block has been included in the application chain ledger. Therefore, if the block has been included in the application chain ledger and other blocks are connected in series afterwards, the following blocks should also be discarded together. After processing, the application chain can be restarted. Selection of members of the proposal group for mining blocks. Of course, it is a rare case that the verification conclusions have been overturned. In most cases, the application chain miners can still maintain the previous verification conclusions after receiving the new inspection report, and will not cause the existing blocks to be frequently invalidated.

It should be pointed out that if the application chain miner has not reached the MaxRounds+Q base chain block generation time at a certain point in time, according to the inspection report that has been received for the block produced by the leader of the proposal group, it has confirmed that the block verification has not passed. , You can directly restart the selection of the members of the proposal group for the block to be mined in the application chain, without waiting any longer. Because the number of reports will only accumulate and will not decrease, once the test conclusion is that the score of the test report that fails is greater than the maximum number of failed verifications, subsequent inspection reports will be received, and the conclusion will not be changed, that is, only the cases where the verification is passed. The conclusion may be reversed. The reason for adding Q base chain block generation times to continue receiving inspection reports is that it takes time for inspection reports to propagate in the application chain, because communication and other factors may cause propagation delays, making the previous verification conclusions not accurate enough.

If the application chain miners are allowed to wait for the inspection report for at most MaxRounds+Q base chain block generation time, it means that the application chain miners allow at most Q+1 consecutive high application chain blocks to be in the verification state. Among them, the block is in the verification state during the period from the selection of the verification group members of the block until the final verification conclusion (referring to the conclusion that can no longer be overturned) is reached. For example, when the application chain block to be mined starts to be verified, at most the blocks with the latest Q+1 height including itself are allowed to be in the verification state at the same time, although the block of the height before the block to be mined in the application chain has been verified and passed , But since the time in the verification state has not reached the time of MaxRounds+Q base chain block generation, the final verification conclusion has not yet been reached. In an ideal state, the base chain and the application chain keep generating blocks at the same frequency (see below for details on the same frequency for block generation), so when the verification waiting time is more than Q base chain block generation time, the application chain in the simultaneous verification state is allowed The number of blocks is Q+1. In special cases, Q can be set to 0, which means that only one application chain block is allowed to be in the verification state.

Driven by the block production of the base chain, the working state of the application chain miners in the mining process will switch between the proposal state and the verification state of the block to be mined. Once a block reaches a verification conclusion (not necessarily If it is the final verification conclusion), the application chain miner will immediately enter the proposal group construction work of the next block. It will confirm whether the proposal group leader has been selected for the next block based on the latest synchronized base chain block information, and then decide whether Continue to form a proposal group. If the leader of the proposal group has been selected in the next block, the next block will enter the verification state directly. If the leader of the proposal group is not selected in the next block, the next block will enter the proposal state, and the application chain miners will start to be It selects members of the proposal group, sends mining requests and other operations. If the application chain miner determines that the leader of the proposal group for a block to be mined has not been selected, it will try to rebuild every time the base chain is produced (corresponding to the application chain miner, it is synchronized to the base chain block information) Proposal group, until the leader of the proposal group of the block to be mined is selected or re-mining a block of an old height is successful.

According to the above explanation, if there are multiple high-level application chain blocks in the verification state at the same time (these blocks must have selected the leader of the proposal group), only when the highest block among them is finally verified, the application chain miners A new proposal group will be organized at a height after this block. For blocks with a non-highest height, even if the final verification conclusion is passed, it will not cause the application chain mine to launch a new proposal group for the next height of the block (because at this time the next height is The block is still in the verification state).

The issue of directional corrosion in the proposal stage has been mentioned in the previous article. For the verification stage, there may also be directional corrosion problems. As a solution, the application chain can avoid directional corrosion by ensuring the number of miners participating in complete verification and improve the security of the blockchain system. For example, if the total number of miners in the application chain is small, the full verification method can be adopted. If the total number of miners in the application chain is large, a verification group can be formed from them, and the minimum number of successful verifications cannot be set too small (for example, you can take tens to several A hundred). When a sufficient number of application chain miners participate in the complete verification of the block, it is very difficult to conduct a comprehensive directional corrosion (the verification result of the block is obtained by statistics, and the directional corrosion of individual verifiers is of little significance).

The main process of the blockchain system provided by the present disclosure for joint mining is described above, and some key issues involved in the operation of the blockchain system are supplemented below:

(1) Block generation problem at the same frequency

In order to maintain the normal operation of the blockchain system in this disclosure, in common implementations, the application chain should maintain basically the same block generation frequency as the base chain (referred to as the same frequency block generation), which is specifically expressed as the largest block of the application chain Gao Chang is in a state of fast catching up with the largest block height of the base chain, usually only a few blocks away, and the reason for maintaining the same frequency for block generation will be analyzed later. However, the inventor found that if the application chain only produces blocks in a conventional manner, the frequency of block generation must be less than that of the base chain. The reason is:

First, the establishment of a proposal group or a verification group on the application chain may fail, causing the application chain miners to fail to produce blocks, which reduces the frequency of application chain blocks. Both the proposal group and the verification group have certain requirements for the number of members. For example, there is a minimum number of miners for the number of members of the proposal group, and the minimum number of successful verifications also implies a requirement for the number of members of the verification group. However, if the members of the proposal group or the verification group are selected using the VRF algorithm, there is bound to be insufficient. Because the result of the VRF algorithm is random, it can only be guaranteed from the probability sense that the number of members selected meets expectations, but it is specific to a certain time. In the process of forming a proposal group or a verification group, the number of members selected may not meet the requirements.

Second, due to poor communication, the election results or inspection reports of the leader of the proposal group were not delivered in time, resulting in the failure of application chain miners to produce blocks, which reduced the frequency of application chain blocks.

Third, even if the base chain has successfully selected the leader of the proposal group for the application chain block, due to the multiple rounds of selection mechanism when forming the verification group, the block may still need to be determined after a few base chain block generations. This also makes the block generation time of the application chain slower than that of the base chain. The expected rounds that the application chain conducts when selecting members of the verification group are related to the design intent of the application chain. For example, if the application chain pays more attention to the full dissemination of messages (such as inspection reports, etc.) between nodes (the more the message dissemination, the more the adversary commits crimes) The more difficult it is), you can conduct more rounds of selection of members of the verification group (try to reduce the proportion of each round being selected).

In contrast, the frequency of block production on the base chain is very certain, which mainly depends on the mining power on the base chain, and is usually not interfered by other factors. In particular, according to the previous explanation, even when a block is produced on the base chain, it is A proposal group leader cannot be selected for a block to be mined on a certain application chain. This time, the election result of the block to be mined is not recorded in the base chain block. That is, the base chain block is not applied Block chain impact.

Therefore, maintaining the same frequency of block generation is actually to increase the block generation frequency of the application chain so that it can catch up with the block generation progress of the base chain. In one implementation, the application chain miner packs the block to be mined in the application chain (the application chain miner may pack it after confirming that he is a member of the proposal group, or may pack it after confirming that he is the leader of the proposal group, such as As mentioned above), it will determine whether the difference between the height of the base chain block of the leader of the proposal group and the height of the block to be mined in the application chain is greater than the preset first difference threshold. If the difference between the two heights is greater than the first The difference threshold is to continuously pack the application chain to be mined blocks and a preset number (at least one) of empty blocks. If the difference between the two heights is not greater than the first difference threshold, only the application chain to be mined blocks are packed. For example, suppose it is determined that the height of the base chain block of the leader of the proposal group is X, the height of the block to be mined in the application chain is Y, and the first difference threshold is 4, if XY>4, the application chain to be mined can be continuously packaged Block and an empty block.

For the continuously packaged application chain to-be-mined blocks and empty blocks, the former is the normal block generation, and the preset number of empty blocks play a filling role. The purpose is to increase the block height of the application chain, thereby increasing the application chain. The frequency of block generation, the empty block does not contain any transaction content. Optionally, a mark may be added to the block header of the block to be mined in the application chain to indicate that it is the first block in the continuous block. When the members of the verification group verify the block produced by the leader of the proposal group, the empty block also participates in the verification, but the conclusion that the verification has passed can be directly given in the verification report.

According to the previous introduction to the election process of the proposal group leader, when the base chain miners pack the base chain blocks, they will determine the application chain to be mined based on the highest block of the application chain recorded in the base chain ledger and the leader of the proposal group has been selected. The height of the block, and the mining request matching the height is selected from the cached mining requests to be included in the waiting set for the block to be mined in the application chain. For the case where application chain miners can produce empty blocks, correspondingly, the base chain miners can determine the height of the base chain block of the leader of the proposal group to determine the application chain to be mined block (this height can be changed from for the application chain to be mined block Is directly extracted from the mining request of the set to be elected) and whether the difference between the height of the block to be mined in the application chain is greater than the preset first difference threshold. If the difference between the two heights is greater than the first difference threshold, it will be marked in The application chain mining union will continuously produce blocks at the height where the block to be mined is located.

Therefore, when base chain miners subsequently determine the maximum block height of the application chain (for example, when collecting mining requests for the next application chain to be mined for the proposal group leader election), they should consider applications marked with continuous block generation The height of the chain. At these heights, the height increase caused by each block of the application chain will be greater than 1. For example, if the application chain miner is allowed to connect two blocks at a time (one of which is an empty block), then the application marked with continuous block generation At the chain height, the height of the application chain will increase by 2 after one block is produced.

If according to the above method, the application chain still cannot catch up with the block generation speed of the base chain, it means that some configuration parameters of the application chain may be poorly selected and need to be adjusted, such as the minimum random value of the election, the minimum number of successful verifications, and the maximum number of failed verifications. Improper setting of other parameters may result in too few members in the selected proposal group or verification group, making it difficult to generate blocks in the application chain.

Optionally, a second difference threshold can be preset for each application chain (the second difference threshold is greater than the first difference threshold), if the base chain miner determines that the difference between the above two heights is greater than the second difference The threshold indicates that the application chain has been unable to catch up with the base chain to produce blocks. In order to avoid a negative impact on the stable operation of the blockchain system, the base chain can refuse to continue to provide computing power support for the application chain. Conversely, if the base chain miner determines that the difference between the above two heights is not greater than the second difference threshold, the application chain should be allowed to continue to catch up with the base chain by generating empty blocks.

In the blockchain system provided by the present disclosure, the base chain usually starts operation earlier than the application chain. Therefore, when the base chain computing power is connected to the newly started application chain, the base chain may have been running for a period of time, as long as the application The initial block height specified by the chain in the genesis block is connected with the current maximum block height of the base chain, and subsequent mining can proceed normally. That is, the first block of the application chain is usually not numbered from 0, but the numbering starts with the block height of the base chain at the time of connection, which is equivalent to the default that the application chain and the base chain are completely synchronized before this.

As mentioned earlier, the frequency of block generation on the base chain is very certain, and it is usually not interfered by factors other than mining power. The application chain is driven by the base chain to produce blocks (for application chain miners through the synchronization of the base chain block information to perceive the base chain to produce blocks) to carry out proposals and verification operations, which is equivalent to the base chain providing a definite clock system for the application chain , May as well call it a clock source, and the timing of various operations performed by the application chain is based on this clock source. The application chain uses the base chain as the clock source to avoid security problems caused by the application chain’s self-defining clock: distributed systems often lack a unified time standard and are easily attacked by the adversary. For example, the number of adversaries among the miners of the application chain chain Excellent, the adversary can control the calculation of the time on the chain, for example, 1 hour is counted as 1 minute to allow time for decryption, targeted attacks, etc. By the way, in addition to the clock source, the first election string used by application chain miners when selecting members of the proposal group and the second election string used when selecting members of the verification group are also from the base chain, and the opponents are the same. It is difficult to manipulate. These two strings can be called random sources (because the election is random). Clock source and random source are the two cornerstones of application chain security, because the clock source and random source are both outside the application chain. System (ie base chain) provided.

After the application chain uses the base chain as a clock source, the frequency of block generation should be consistent with that of the base chain as much as possible. Otherwise, the fluctuation amplitude of the generation time interval of every two adjacent blocks in the application chain will increase, which is not good for the smooth block generation of the application chain. . In some upper-level applications of the application chain (such as transaction transfer), the block generation time of the application chain block is taken as the time node related to the business process or the basis for calculating these time nodes. The fluctuation of the block generation time will directly affect the business time The accuracy of judgment. If the application chain can produce blocks at the same frequency as the base chain, the cumulative effect of block generation time deviation can be avoided (the average block generation time of the application chain after inserting empty blocks in the application chain will converge to the base chain). It should also be pointed out that, as a special measure to maintain the same frequency, the empty block should avoid interference with the timing logic of the application chain itself. For example, the process of empty block generation can be logically understood as occupying 0 hours. If the upper-level application of the application chain wants to use the block generation time of the application chain block, the time span between the empty block and the previous non-empty block should be regarded as 0 duration.

(2) Soft fork and longest chain problem

In a typical blockchain public chain system, each miner independently decides when to produce a block. For example, in the Bitcoin system, a miner randomly collides with a hash value that meets the difficulty factor requirement, and the computing power competition wins. The miners then broadcast the whole chain of the new blocks they have packaged. This approach will inevitably lead to multiple miners packing blocks of the same height at the same time, that is, soft forks in the ledger are inevitable. The existing public chain system generally eliminates soft forks through the longest chain mechanism, which involves the longest chain switching operation. For details, please refer to the prior art, which will not be elaborated here. Although the soft fork will not make the public chain system inoperable, if it occurs frequently, the longest chain switching operation must be performed frequently, resulting in frequent rollbacks of accounted transactions, thereby affecting the robustness of the system. Therefore, it is necessary to suppress soft forks or weaken the impact of soft forks as much as possible.

In the blockchain system provided by the present disclosure, the base chain inherits the above-mentioned soft fork characteristics in the existing public chain system (but it does not mean that the base chain must be a public chain), and also adopts the most used in the existing public chain system. Long chain mechanism to eliminate soft forks.

Since the application chain relies on the computing power support of the base chain, its soft fork has two sources: First, the autonomous mining behavior of the application chain miners will lead to a soft fork (the above-mentioned soft fork characteristics in the existing public chain system) ); Second, the soft fork that appears in the base chain must be mapped to the application chain, making the application chain form a soft fork, because the application chain miners need to synchronize the base chain block information from the base chain to form a local base chain ledger, which is different Application chain miners connect to the base chain at different locations, so that the soft forks that appear in the base chain are also synchronized separately, causing each application chain miner to only recognize the leader of the proposal group indicated in the base chain block information that it has synchronized to. Only the block generated by the leader of the proposal group is verified. The application chain also follows the longest chain mechanism. The soft forks caused by the above two reasons are also eliminated by the longest chain mechanism, and the longest chain switch caused by these two reasons may not necessarily point to the same longest chain of the application chain. This makes the longest chain switching process used to eliminate soft forks on the application chain more complicated, which will be explained in detail later.

The following features in the blockchain system provided by the present disclosure help to relieve the interference caused by the soft fork of the base chain:

First, the mining request of the application chain miners will be broadcast in the base chain, and each base chain miner will receive the mining request, and based on these mining requests, the same proposal group leader will be selected for the same height block of the application chain. The probability is higher. Moreover, in the solution of the present disclosure, the proposal stage is more restrictive than the verification stage (for example, in a common implementation, new miners who have never participated in mining will also give them the first accounting weight to allow them to mine, while holding Miners whose currency is less than the minimum currency holdings are not allowed to participate in the selection of members of the verification group), which is also conducive to the convergence of the election results of the leaders of the proposal group. Therefore, regardless of whether the base chain has a soft fork, it has little effect on the results of the election of the leader of the proposal group.

Second, the first aspect, the first election string used by the application chain when selecting the members of the proposal group of the block to be mined in the application chain is based on the first L area of the base chain block of the leader of the proposal group to determine the block to be mined in the application chain The information in the block is basically fixed (especially when L takes a larger value, such as 6). Therefore, if the base chain has a soft fork after the source block of the first election string, the application chain also has a soft fork. For the block to be mined at a certain height after the application chain, regardless of whether the block is located in the application chain. On which candidate branch of the chain, the value of the first election string obtained is likely to be the same, and the final proposal group leader is also likely to be the same, because the proposal group leader election algorithm on each base chain miner is the same. Only the arrival of mining requests is inconsistent and there is interference (if the mining requests received by the base chain miners are inconsistent, there is a certain probability that different proposal group leaders will be selected).

In the second aspect, after the base chain determines the leader of the proposal group for the block to be mined in the application chain, the second election string used when the application chain selects the members of the verification group is calculated based on the following information: the miner identification of the proposal group leader, and the proposal is determined The height of the group leader's base chain block, the height of the application chain to be mined and the round number of the selection verification group members, this design can effectively prevent the interference of the base chain bifurcation during the selection process of the verification group members. The reason is that the two information of the miner identification of the leader of the proposal group and the height of the block to be mined in the application chain are determined during the selection of multiple rounds of verification group members, and the base chain is selecting the proposal group of the block to be mined in the application chain. The subsequent soft fork of the leader does not affect the value of determining the height of the base chain block of the leader of the proposal group, and the subsequent soft fork of the application chain due to the soft fork of the base chain does not affect the selection verification The value of the round number of the group members.

Based on the above two aspects, there is a high probability that the soft fork of the base chain and the application chain will not interfere with the election of the leader of the proposal group and the selection of the members of the verification group, and the application chain block generation and verification process has a high degree of certainty.

Third: If the miners on the base chain select two or more proposal group leaders for the same application chain to be mined, it will cause the base chain to undergo a soft fork, and the application chain will also undergo a soft fork. After the fork, the block generation speed of the application chain slows down, the block generation speed of the base chain remains unchanged, and the soft fork will be quickly eliminated. There is an adaptive adjustment mechanism for the difference in block generation speed between the base chain and the application chain. The details are as follows:

If the soft fork of the application chain is caused by the above reasons, after the soft fork, there will be multiple proposal group leaders on the application chain to produce blocks for verification, and the miners participating in the verification will be diverted, which objectively makes verification more difficult to pass. In addition, the administrator of the application chain can also adjust the two parameters of the minimum number of successful verifications and the maximum number of failed verifications configured on the application chain. Increase the minimum number of successful verifications and reduce the maximum number of failed verifications, so that the conditions for passing verification will be reduced. It is more demanding, and it is more difficult for the block to pass verification, especially the block produced by the leader of the proposal group approved by only a few verification group members will not be able to pass the verification.

As the difficulty of passing verification increases, the block generation speed of the application chain will slow down. On the one hand, the number of rounds for selecting verification group members will increase (only more verification group members are selected to pass verification), and verification is time-consuming It will become longer. On the other hand, once the block fails to pass verification, the application chain miners can only continue mining at the original height, and the application chain height will not increase. After the mining progress of the application chain slows down, the degree of soft forks already generated on the application chain will not continue to deepen, which is conducive to the convergence of the forks. Moreover, after the block height growth of the application chain slows down, the block frequency of the base chain will not be affected, and the soft fork generated on the base chain will be quickly eliminated.

After the soft fork of the base chain is eliminated, the application chain will return to the state of normal mining (but at this time the soft fork on the application chain may not have been eliminated), the side effect is that there will be vacancies on the application chain for a period of time. There will be more blocks in order to recover the block height difference with the base chain. At this time, the probability that the block in the candidate branch maintained by the application chain miner in the active area (the meaning is explained below) (hereinafter referred to as the active branch) will pass through several rounds of verification is relative to the application chain miner in the inactive area. The block in the candidate branch (hereinafter referred to as the inactive branch) is higher. As a result, it is easier to increase the block height on the active branch, and because the application chain continuously produces more blocks, the height difference between the active branch and the inactive branch will quickly widen, and the active branch will be determined in a short period of time For the longest chain of the application chain, the soft fork on the application chain is also eliminated. Among them, the active area is a community composed of nodes with smooth communication in the blockchain system. The nodes in the active area are often distributed and concentrated, the information between the nodes is synchronized in time, and the number of nodes also accounts for the majority of the system.

If the soft bifurcation of the application chain is not caused by the soft bifurcation of the base chain, it can be analyzed similarly and will not be elaborated. The following continues to introduce the longest chain switching process on the application chain.

A. Double longest chain switching

As mentioned earlier, there are two factors that lead to the soft fork of the application chain, one is caused by the independent mining of miners in the chain, and the other is caused by the soft fork of the base chain. Two types of longest chain switching rules are correspondingly set in the application chain to eliminate soft forks caused by these two factors. Among them, the first longest chain switch is triggered by the block synchronization between miners in the application chain, and the second longest chain switch uses the longest chain switch of the base chain to trigger the longest chain switch of the application chain. . No matter which type of the longest chain switch, the successful accounting of each block on the candidate branch of the application chain as the switch target is used as the switch end sign.

There is a credibility problem in triggering the longest chain switch. A miner receives a new block and causes the longest chain switch. The newly received block can be just a block header or a complete block, but it is required that it cannot be forged at will, because the longest chain Switching involves a transaction rollback operation, and the processing process is relatively heavy. If a block is easily forged and the candidate branch is switched, the blockchain system will become very fragile. Take the Bitcoin system as an example. Bitcoin only needs the block header to drive the longest chain switch, because hash collisions are restricted by the difficulty of mining, and forging the block header is as difficult as forging the block body. In the practice of the blockchain, the block header and the block body are mostly distributed separately. Because the amount of data in the block header is small, it is easy to quickly propagate in order to perform subsequent operations. Of course, the method of block propagation as a whole is not ruled out. However, for the sake of simplicity, the following introduction still assumes that the application chain block uses the method of separate propagation of the block header and the block body in the application chain. Among them, the block header can be propagated first, and the block body is taken to adjacent nodes. How to ask for it. If the application chain block is spread in other ways, similar analysis can also be done.

In the solution of the present disclosure, after the application chain miner incorporates the block header of a certain application chain block into the application chain ledger, if it is found that the attachment of the block header causes a certain application chain candidate branch to become the highest among all candidate branches. If it is long, it triggers the first longest chain switch, and the block body of the application chain block can be requested from other application chain miners later.

After the application chain miner incorporates the synchronized base chain block information into the local base chain ledger, the second longest chain switch is triggered after the longest chain switch is generated in the local base chain ledger. As mentioned before, there are several forms of base chain block information, but no matter which form, at least it includes the block header of the base chain block and the block body of the base chain block. The proposal for the block to be mined in the application chain The election result of the group leader cannot only include the block header of the base chain block, because if the information of the leader of the proposal group is missing, the application chain miners cannot perform subsequent verification and mining operations. After the application chain miner confirms that the longest chain switch of the base chain occurs, the branch of the application chain for mining is switched to the longest chain of the application chain indicated by the longest chain of the base chain through the second longest chain switch (referred to as the application chain waiting Switch branches). However, since the longest chain of the base chain and the longest chain of the application chain may not be exactly the same (because there are behaviors such as re-digging old blocks), the branch to be switched of the application chain at this time is not necessarily the block height In the sense, the application chain is the longest chain, but it does not affect the application chain miners to switch the longest chain under the instructions of the base chain.

Since the longest chain switch involves transaction rollback operations, other transaction-related operations cannot be performed before the switch is completed, including prohibiting the interleaving of the two longest chain switches. The so-called interleaving refers to the execution of one of the types of the longest chain switch Execute another type of longest chain switch at the same time. The two types of longest chain switch can only be executed in time sharing or if they are executed at the same time, one of them must be terminated. The specific execution rules are:

First, in the process of the application chain miner executing the triggered first and longest chain switch, if there is a newly triggered first or second longest chain switch, the application chain miner will not respond. Continue to perform the current first longest chain switch.

Second, when the application chain miner executes the triggered second longest chain switch, if a new second longest chain switch is triggered, the application chain miner terminates the second longest chain that is being executed Switch, and start to execute the newly triggered second longest chain switch.

Third, in the process of the application chain miner executing the triggered second and longest chain switch, if a new first and longest chain switch is triggered, determine the leader of the determined proposal group indicated by the longest chain of the base chain Whether the highest height of the human application chain block (that is, the height of the branch to be switched in the second longest chain switch) is less than the height of the candidate branch of the application chain that includes the block header that triggers the first longest chain switch . If the previous height is smaller than the latter height, it indicates that the application chain candidate branch corresponding to the first longest chain switch is higher. At this time, the application chain miner terminates the second longest chain switch that is being executed, and starts to execute the newly triggered one The first and longest chain switch, if not, the application chain miner does not respond to the newly triggered first and longest chain switch, and continues to execute the current second and longest chain switch.

When the first and longest chain switch is generated, the processing method can refer to the implementation in existing blockchain systems such as Bitcoin or Ethereum, which will not be elaborated here.

When the second longest chain switch occurs, the application chain miners may find that the block header of one or more recent blocks on the branch to be switched on the application chain is missing (the application chain is in the branch to be switched when the first longest chain is switched Block headers will not be missing), these blocks with missing headers may be saved by other miners in the application chain and have not yet been transmitted. This is a temporary loss, because since the second longest chain is switched to the longest chain of the base chain. The block before the maximum height of the branch to be switched in the application chain indicated by the longest chain of the base chain must have been successfully produced. Otherwise, the application chain miners will not initiate a target download if the previous block is not successfully produced. For a mining request for a block, the base chain will not select a leader of the proposal group for it. However, these blocks with missing block headers may not yet exist in this chain. This is a true lack. Because the base chain synchronization node accessed by the application chain miners only maintains data synchronization in a local area of the base chain, some of the base chain’s The candidate branch may not have been synchronized with any miner in the current application chain, or although it has been synchronized, the base chain block information is lost at the time of synchronization, etc., resulting in no corresponding application chain block on the application chain.

Temporary missing and true missing of application chain blocks need to be distinguished. Temporary missing can still be compensated by data synchronization between application chain miners; true missing is that although the base chain has selected the leader of the proposal group, there is no miner in the application chain Knowing that the leader of the proposal group has been elected, no miners produce blocks, or the application chain miners who have been elected leaders of the proposal group have produced blocks, but failed to propagate new blocks due to abnormal communication. In short, they cannot pass the application chain miners. Synchronously replenish the data between them. Both of these two kinds of defects can be effectively dealt with in the second heavy and longest chain switching scheme of the present disclosure.

The application chain miner performs the second longest chain switch. The overall process is: first determine the last confirmed block on the branch of the application chain to be switched. The confirmed block means that the block header has been received by the application chain miner. And the application chain miner has determined the verified block according to the received inspection report (the block body can be obtained from other application chain miners later). At this time, the block header is in a state that can be written to the application chain ledger, as to whether it will be written The entry book is related to realization. Then, the application chain miner starts from the block after the confirmed block, traverses the application chain to be switched branches in the forward direction (in the direction of block height increase), and incorporates the blocks on the application chain to be switched branches into the application during the traversal process In the chain ledger.

In a specific implementation manner, the above-mentioned second heavy and longest chain switching process can be operated according to the following steps. Note that the empty blocks on the application chain are not involved in the following operations, and these empty blocks can be skipped and not processed.

In the first step, application chain miners start from the last block of the longest base chain in the local base chain ledger, traverse the longest chain of the base chain in the reverse direction (the direction of block height reduction), and analyze the leaders of each selected proposal group. Whether the person's block has been confirmed on the pending branch of the application chain, the first confirmed block found is the last confirmed block on the pending branch of the application chain.

If the last confirmed block on the branch to be switched on the application chain is not the last block on the branch to be switched on the application chain, the first selected proposal group indicated by the base chain after the last confirmed block The leader's block is determined as the first block to be determined, and the first block to be determined is confirmed within the block time of at most Z base chains. If the first block to be determined has not been confirmed by the application chain miners after waiting for at most Z base chain block time, the second longest chain switch will be terminated, and the selection of the proposal group members of the first block to be determined will be restarted. Among them, Z is a positive integer. If the first block to be determined is the last block on the branch to be switched on the application chain, Z can be MaxRounds+Q, otherwise Z can be a value not less than MaxRounds+Q; MaxRounds is recommended and verified by application chain miners The maximum round of group members, Q is the number of heights of additional blocks allowed by the application chain miners to be in the verification state at the same time. The meaning of these two parameters has been introduced above.

If the last confirmed block is the last block on the branch of the application chain to be switched, the next block of the last confirmed block is determined as the next block to be mined in the application chain and the block is started Selection of members of the proposal group.

In the second step, the application chain miner judges whether the leader of the proposal group of the first block to be determined is himself. If the leader of the proposal group for the first block to be determined is the application chain miner, it is further judged whether the application chain miner has packaged the pending first block. If the pending first block has been packaged, the packaged pending first block is reused. If the first block to be determined has not been packaged, the first block to be determined is packaged. Regardless of whether the first block to be determined has been packaged or not, the application chain miners should broadcast the pending first block to other application chain miners and begin to participate in the selection of the verification group members of the pending first block. The application chain mining tool has a caching mechanism, and the recently packaged blocks will be cached. If the longest chain of the application chain switches back and forth between candidate branches several times, a certain block has been packaged and cached locally in the application chain miners. It is entirely possible that the previously constructed block can be reused directly at this time. For the case where the first block to be determined needs to be packaged, it indicates that the block is not in the local cache. For example, although the base chain has selected the proposal group leader for this block, the application chain miner did not know that he was the proposal group leader before , So we need to do the rebuild operation of the new block (if the rebuild fails, the application chain miners will restart the mining at the height of the first block to be determined after the Z base chain block generation time comes, see the description of the third step below), This situation corresponds to the actual lack of blocks described above. If the leader of the proposal group for the first block to be determined is not the application chain miners themselves, they can directly start the selection of members of the verification group for the first block to be determined.

In the third step, application chain miners monitor the verification progress of the first block to be determined. If the first block to be determined is included in the application chain ledger within the Z base chain block generation time since the application chain miners start to select the proposal group members of the first block to be determined, the first block after the first block to be determined will be instructed by the base chain The block in which the leader of the proposal group has been selected is determined as the next first block to be determined. If the first block to be determined is not included in the application chain ledger within the Z base chain block generation time since the application chain miners started to select the proposal group members of the first block to be determined, the second longest chain switch will be terminated and the second longest chain switch will be restarted. Selection of the members of the proposal group for the first block. Among them, the definition of Z is the same as in the previous step. It should be noted that the inclusion of the first block to be determined into the application chain ledger means that the entire block of the first block to be determined is written into the application chain ledger, not just the block header, which is different from block confirmation. In this step, the purpose of monitoring the application chain miners is mainly to avoid the mining node where the selected proposal group leader is abnormally offline, or has been shut down and exited. If such an abnormal situation is not dealt with, the application chain will easily hang up. live.

In the fourth step, the application chain miners determine whether the next pending first block has been confirmed (because a period of time has passed since the last confirmed block of the branch to be switched in the application chain has been processed, and the next pending first block It may have been confirmed), if the next pending first block has been confirmed, or if it has not been confirmed at present but it is confirmed after waiting for at most Z base chain block time, then try to include the next pending first block into the application chain The specific method of the ledger is similar to the processing of the first block to be determined in the above steps, that is, the processing of the first block to be determined is a cyclic process, and the description will not be repeated. If the next pending first block has not been confirmed by the application chain miners after waiting for at most Z base chain block time, the second longest chain switch will be terminated, and the proposal group members of the next pending first block will be restarted Selection.

The application chain miner continues to traverse the pending branch of the application chain forward to find the subsequent pending first block, until the block on the pending branch of the application chain is included in the application chain ledger, ending the second longest chain switch. If a new second and longest chain switch is triggered during the execution of the second and longest chain switch, the application chain miner terminates the second and longest chain switch that is being executed, and uses the new longest chain of the base chain. Based on the longest chain of the indicated application chain, go back to the first step above to execute the newly triggered second longest chain switch.

From the perspective of the longest chain switch, only the block header can be driven, but in the process of the second and longest chain switch of the application chain, there are two things that must rely on the block body to proceed: one is When verifying a block, in order to verify the legitimacy of the transaction, the block body must be used, because the transaction is stored in the block body; the second is that the application chain miner needs to be sure before starting the mining work of the next block. Which transactions can be included in the new block, so it must be clear which transactions have been accounted for before, which also requires the use of block bodies.

For the verification process in the second longest chain switch, application chain miners only perform verification operations based on the block content (including block header and block body) when they confirm that they are members of the verification group. If the block content is found to be lacking (There is only a block header but no block body, corresponding to the temporary loss of the block mentioned above) first ask for the corresponding block body from the neighboring node, verify the block body and broadcast the inspection report, otherwise verify the members of the team Waiting for status: Or, waiting for the inspection report issued by other verification team members, and quitting when a conclusion of passing or failing the verification is reached based on the received inspection report, or waiting for exceeding the preset time limit (For example, Z base chain block time) then exit dead and so on. For application chain miners who are not members of the verification group, they only need to rely on the inspection report broadcasted by the verification group members to decide whether to adopt the corresponding block according to the established rules. The specific rules are the same as those in the previous ordinary mining (non-longest chain switching).

Due to the soft fork of the application chain, and the inspection reports in the distributed system cannot arrive in a definite time and order, it is possible to require all application chain miners to cache the received inspection reports (automatically delete them when they expire). When the longest chain switch occurs in the chain, the application chain miner scans the cache area and selects the inspection report that matches the block to be inspected (the block miner and the block height match) autonomously decide whether to adopt the corresponding block according to the established rules. It may even happen that the current candidate branch is switched to another branch, but switched back after a period of time, because the branch that was cut has returned to the longest chain of the application chain, which has been used in history. The inspection report may be reused repeatedly.

For the proposal process in the second longest chain switch, after the application chain miner confirms that he is a member of the proposal group, before packaging a new block, it needs to ensure that the contents of each block have been collected and written into the local ledger (e.g., You can ask for the corresponding block body from the neighboring node), if you have confiscated the whole, you should wait for it first (for example, wait for at most Z base chain block time), if it expires, restart the mining work at the height of the first block currently pending.

B. Optimization of double longest chain switching

As mentioned above, the double longest chain switching involves both the soft fork and branch switching caused by the application chain itself encountering the longest chain, and the soft fork and branch switching of the application chain caused by the base chain encountering the longest chain switching. Branch switching, these two kinds of switching have interactive effects, and the processing process is more complicated. The soft fork of the base chain may cause two (or more) results in the election of the leader of the proposal group of the block of the specified height of the application chain. After the election results are recorded in the base chain block and synchronized by the application chain miners, the application chain For the same block height, two (or more) miners may be elected as the leaders of the proposal group. In an optional scheme, it is normal to select multiple proposal group leaders for the same block height from the application chain miners (that is, allowing multiple application chain miners to produce blocks at the same height at the same time), The optimization of the longest chain switching algorithm allows the application chain system to optimally select the bifurcation path when multiple miners produce blocks at the same block height, thereby reducing the uncertainty and processing complexity in the longest chain switching Sex. The specific plan is as follows:

For a certain application chain miner, the proposal group leader of the application chain block at the first height in its local application chain ledger (that is, the application chain miner who created the block) is called the old proposal group leader, that is, the current proposal group leader The leader of the known, highest-level application chain block proposal group. Among them, the first height is not a specific height in the application chain, but generally refers to a certain height in the application chain. Regarding the leader of the proposal group corresponding to the application chain block, there may be the following ways to obtain:

First, as mentioned above, while broadcasting the application chain block, the application chain miner can also broadcast the proposal candidate information corresponding to the leader of the proposal group that created the block, or the proposal candidate information corresponding to the leader of the proposal group It may be recorded in the Coinbase of the block. The proposal candidate information includes the public key of the leader of the proposal group, so that the application chain miner can learn the identity information of the block creator after receiving the broadcast block.

Second, the application chain mining union synchronizes the base chain block information from the base chain, and the election results of the proposal group leader in the base chain block information, so that the application chain miners can also learn the identity information of the block creator.

Since the first-level application chain block has been incorporated into the application chain miner's local application chain ledger, the identity of the old proposal group leader's application chain miner is known.

After the soft fork of the base chain, two (or more) blocks related to the same election on different branches may choose two (or more) different proposal group leaders for the same application chain with the same height block people. The reason is probably due to poor communication. The set of mining requests sent by miners in the application chain is not exactly the same for each miner node of the base chain. That is, some nodes of the base chain may miss messages. . Here, let’s take the example of two proposal group leaders selected by the base chain as the block of the application chain at the first height. The two proposal group leaders, and the application chain miners who have already known their identities are called the old proposal group leaders. The person, as mentioned above, who has not yet known his identity is called the leader of the new proposal group.

Application chain miners can learn through different channels that there are new proposal group leaders who are different from the old proposal group leaders for the first-level application chain block. For example, according to what has been mentioned above, when an application chain miner receives the first-highest application chain block broadcast by other application chain miners, it will be based on the proposal candidate information recorded in the block or the proposal that is broadcast with the block. Candidate information can determine that there is a new proposal group leader who is different from the old proposal group leader for the first-level application chain block. For another example, the application chain miner can also determine that there is a new proposal group leader different from the old proposal group leader for the first-level application chain block based on the synchronized base chain block information. In particular, if the leader of the new proposal group is the current application chain miner itself, this information can be confirmed in the latter way. Of course, in most cases, there is no new proposal group leader different from the old proposal group leader for the application chain block of the first height, and the subsequent "longest chain switch" will not be triggered at this time.

Optionally, when the application chain miner receives the block created by the leader of the new proposal group, it can also verify whether the leader of the new proposal group is truly a member of the proposal group of the application chain block at the highest level. If not, Then the application chain block created by it will be ignored, and subsequent steps such as comparing priority will not be carried out.

After that, the application chain mining union judges whether the priority of the new proposal group leader is higher than the priority of the old proposal group leader. If the priority of the new proposal group leader is higher than the priority of the old proposal group leader, it will proceed. "Longest chain switch", that is, the application chain block of the first height created by the leader of the old proposal group on the current main branch of the application chain ledger is switched to the first height application created by the leader of the new proposal group The first-highest application chain block created by the leader of the old proposal group was changed to be a block in a non-master branch. If the priority of the leader of the new proposal group is not higher than the priority of the leader of the old proposal group, the first-highest application chain block created by the leader of the new proposal group can be ignored, and the current main branch remains unchanged. After the switch is completed, the application chain miners can continue to broadcast the first-highest application chain block created by the leader of the new proposal group to other application chain miners.

When the application chain miners re-establish the proposal group leader of the first-highest application chain block, the first-highest application chain block created by the new proposal group leader may have just been received from other application chain miners (for example, new The leader of the proposal group originally confirmed it when the new block was received), or it may have been received before (for example, before the application chain miner synchronizes the base chain block information and confirms the existence of the new proposal group leader, the new proposal group leader People have already created and broadcast the block). In the latter case, you only need to find the first-highest application chain block created by the leader of the new proposal group from the locally cached application chain block.

It is understandable that the main branch switch triggered by the leader of the proposal group redetermined does not require that the soft fork that is newly cut into the main branch must be on the longest chain in the sense of block height, that is, the main branch after the switch. The branch may not be the longest chain in the sense of block height, but for the convenience of description, this switch can still be called the "longest chain switch". However, if the longest chain switch is triggered by receiving a new block to form the longest chain on a non-master branch, the master branch after the switch must become the longest chain known to the current node.

The following explains how to use the second random value to compare the priorities of two proposal group leaders. Of course, it does not rule out defining the priority of proposal group leaders in other ways:

First, obtain the second random value used by the new proposal leader when being selected as a member of the proposal group, and the second random value used by the old proposal leader when being selected as a member of the proposal group. Regarding the calculation of the second random value, it has been explained when introducing the members of the selection proposal group, and the explanation will not be repeated. According to the foregoing description, the calculation of the second random value needs to rely on information, for example, the first provable string, the weight of the proposal group participation, etc. are attached to the broadcast message or directly recorded in the Coinbase of the block. Or, in some solutions, if the second random value is already carried in the Coinbase of the broadcast message or block, it can also be used directly without re-deriving it.

Then, determine whether the second random value corresponding to the new proposal leader is greater than the second random value corresponding to the old proposal leader. If the second random value corresponding to the new proposal leader is greater than the second random value corresponding to the old proposal leader, then Determine that the priority of the leader of the new proposal group is higher than the priority of the leader of the old proposal group; otherwise, determine that the priority of the leader of the new proposal group is not higher than the priority of the leader of the old proposal group.

In particular, if the second random value of the two are exactly the same, or it can be considered that the priority of the leader of the new proposal group is not higher than the priority of the leader of the old proposal group, it is the final priority comparison result (the “most Long chain switching”), or the priority of the two can be further compared through additional distinguishing information (for example, the public key of the miner corresponding to the leader of the proposal group).

In some implementations, the above-mentioned first height is also limited, and the application chain block of the first height cannot be a block too early, otherwise the stability of mining may be affected. For example, it can be defined that the difference between the first height and the maximum block height in the application chain ledger should be less than the preset height difference (for example, it can be 6). In other words, even if the application chain miners find that the first height of the application chain block has a new proposal group leader that is different from the old proposal group leader, if it is judged that the difference between the first height and the maximum block height in the application chain ledger is not If the height difference is smaller than the preset height, the block created by the leader of the new proposal group will be ignored, priority comparison will not be carried out, and the “longest chain switch” will not be carried out. Only when the first height is judged to be in the application chain ledger The priority comparison will only be performed when the difference between the maximum block height of is smaller than the preset height difference.

If the application chain miner performs the "longest chain switch", it will further drive the tail of the newly switched terminal branch in the main branch (blocks with a height greater than the first height) to synchronize with adjacent miner nodes, including , Broadcast the blocks in the stub branch that you already own to neighboring miner nodes, and ask neighboring miner nodes for the data of subsequent blocks in the new stub branch.

Although the above only introduced the selection of two different proposal group leaders for the same height block of the application chain, the situation of selecting more different proposal group leaders for the same height block of the application chain is similar. , When comparing the priorities of the leaders of the proposal group, the method of pairwise comparison can still be used, and the explanation will not be repeated.

(3) Ledger compression problem

After the blockchain system runs for a long time, the volume of the ledger will become larger and larger. In order to save the storage space on the blockchain node, the ledger can be compressed. The following is an example of the compression of the base chain ledger stored locally by the base chain miners:

For the election basis list in the base chain block, it only serves the mining of new blocks, and there is no need to keep it for a long time. For example, in one implementation, the base chain block can be stored as follows:

Blocks generated during the last D difficulty adjustment cycles of the base chain save the block header and the complete block body; blocks generated before the last D difficulty adjustment cycles of the base chain save the block header and elections in the block body The result list, but does not save the election basis list. Among them, D takes a positive integer, for example, the most recent D difficulty adjustment cycles may correspond to the most recent ten days, one or two months, etc. If the entries in the election result list are in a simplified form (only the miner identification of the leader of the proposal group), the candidate information of the proposal generated by the leader of the proposal group in the election basis list should also be saved (if the entries in the election result list are not included) In the simplified form, the required proposal candidate information is already included). If digital currency is issued on the base chain, transaction information must be stored in the block body to determine the account balance. In the specific implementation, after the new base chain block is verified, the base chain miners can first include it in the base chain ledger, and regularly clean the base chain ledger, that is, remove the election basis list in the block. Realize ledger compression.

For the base chain blocks generated before the most recent D difficulty adjustment period, it is sufficient to verify the information based on the retained information. Take the simplified form of the entries in the election result list in the block as an example: it is necessary to prove the records in the entries The miner ID of the leader of the proposal group has not been forged, just derive the merkle root, and then confirm that the deduced result is consistent with the merkle_root1 recorded in the block header. To prove that the content of the proposal candidate information generated by the leader of the proposal group is true and credible, firstly derive the miner ID of the proposal group leader based on the proposal candidate information, and confirm that the deduction result is consistent with the record in the list of election results; Then the first election string can be obtained by using the item of the height of the base chain block of the leader of the proposal group in the proposal candidate information, and then based on the application chain miner’s public key and the first provable string in the proposal candidate information. The item information and the obtained first election string call the verification function of the VRF algorithm to confirm that the first provable string is not forged.

When a miner in the application chain needs to rebuild the application chain ledger (for example, the mining node where the miner is located is restarted after a failure), it is necessary to verify whether each block in the ledger is legal. For any application chain block to be verified, application chain miners at least need to synchronize the block header of the base chain block that records the election results of the block from the base chain and the leader of the proposal group selected for the block in the block body Person’s corresponding proposal candidate information (from the above description, these two contents are included in each base chain block regardless of whether the base chain ledger is compressed), and confirm whether the application chain block is correct according to the synchronized information Obtained by the base chain, the specific process includes:

After the application chain miner synchronizes the above information, the above-mentioned method can be used to confirm that the first provable string in the proposal candidate information is not forged; then, the proposal candidate needs to be confirmed according to the application chain miner public key in the proposal candidate information The leader of the proposal group identified by the information is the block producer of the application chain block to be verified. For example, the block producer’s public key information can be stored in the block header of the application chain block, and the public key information obtained from the application chain miner can be confirmed The public key information should be consistent with the public key information stored in the block header.

In some optional solutions, after the application chain miner has confirmed that the first provable string in the proposal candidate information has not been forged, the first provable string can be further used to derive the first random value and the second random value ( See the above for the specific formula), and finally verify whether the second random value meets the conditions for being elected members of the proposal group and whether it meets the basic requirements of the elected proposal group leader. Of course, if the second random value is already included in the implementation of the proposal candidate information, and the application chain miners are eager to catch up with the block height when rebuilding the ledger, they can also directly use the second random value in the proposal candidate information for verification. Then derive it based on the first provable string.

It is very important for application chain miners to synchronize information from the base chain when rebuilding the application chain ledger to confirm that the blocks in the ledger are recognized by the base chain, because the application chain ledger is easy to be forged. If the base chain is missing to endorse it, its authenticity will be Greatly discounted.

To sum up, in the blockchain accounting method provided in this disclosure, the application chain miners do not directly run the consensus algorithm to compete for the block right, but send a mining request to the base chain miners after determining that they are members of the proposal group , The base chain miners elect the leader of the proposal group through calculations and record the election results and election basis in the base chain block, and then the application chain miners can obtain the information of the proposal group leader by synchronizing the base chain block information, and then Participate in the selection of the members of the verification group, and judge whether the block has passed verification by collecting the verification reports made by the members of the verification group on the block produced by the leader of the proposal group. If the verification is passed, the account will be kept.

In practice, there are some special circumstances in this blockchain accounting method, which are briefly explained below:

In the schemes introduced above, the base chain miners are responsible for the election of the proposal group leader. However, in practice, there are some cases where the application chain miners elect the proposal group leader by themselves. Of course, the election process still depends on the base chain. Synchronized information.

For example, some application chains want to limit the election of proposal group leaders from a certain range of miners, then miners in these application chains can use the "random source" provided by the base chain to determine blocks of any height by the proposal group Which one of the members assumes the leadership role. Among them, the so-called miner group within a certain range means that the list of proposal group members is fixed (can be pre-configured in the program), for example, proposal group members can be senior members of the application chain, board members, etc., depending on user needs Depends. The concept of "random source" has already been introduced in the previous section. The "random source" in this solution can include the first election string determined by preset rules. The content of the first election string is random and is based on the first election. String, application chain miners can dynamically elect a proposal group leader from a certain range of proposal group members.

For example, the first election string is still recorded as info, and the members of the proposal group are numbered from 0 to N-1. The application chain miner can calculate the number of a proposal group member by calculating the value of info%N, that is, The number of the miner who is the leader of the proposal group, where N is the total number of members of the proposal group, and% represents the remainder operation. It should be pointed out that in these special cases, although the base chain miners did not directly participate in the election process of the leader of the proposal group, the application chain miners still need to use the local base chain ledger when calculating the first election string (see the previous section for details) The method of determining the first election string), therefore, the step of applying chain miners to synchronize the block information of the base chain is still necessary.

After the election of the leader of the proposal group, the leader packs the application chain to be mined and submits it in this application chain, and the application chain subsequently forms a verification group to carry out verification and other operations similar to those introduced in the previous article, and will not be repeated.

In short, the blockchain accounting method provided by the embodiments of this application actually provides a new mechanism for the base chain and the application chain to participate in mining. One base chain can gather mining machine resources and provide computing power for many application chains. Service, assist the application chain to complete the mining process, which can effectively improve the waste of mining machine resources in the existing blockchain system, and has good social benefits. Among them, the base chain and the application chain can be either a single chain or a parallel chain, and the block chain system composed of the base chain and the application chain can also be nested, which is very flexible. The above first introduces the working principle of the base chain and the blockchain for joint mining, and then analyzes the difficult issues involved in the same frequency block, soft fork and longest chain, and ledger compression. Corresponding solutions have been developed to improve the joint mining mechanism.

After research, the inventor believes that this method can be used in, but not limited to, the following scenarios:

Scenario 1: For the newly developed blockchain system, it will inevitably encounter the natural contradiction between growth and security. When the new system was launched, due to the lack of mining machine resources, the pooled computing power was insufficient and easy to be attacked. Real cases have confirmed this. There are already several blockchain systems from the Bitcoin hard fork. The premeditated computing power attack failed. The more insecure the blockchain system is, the harder it is to win the trust of the public, and the less people use it. The less people use it, the less mining machines participate, and the blockchain system tends to be more insecure. The entire system will fall into a vicious circle.

Although the design of a proprietary consensus algorithm for the blockchain system can avoid computing power attacks to a certain extent, it will inevitably lead to the lack of versatility of the mining machine and it will be difficult for the market to recognize it. In the end, it will not be able to solve the plight of the new system lacking computing power support.

If the blockchain accounting method provided in the present disclosure is used, the base chain can provide sufficient mining machine resources for the newly developed blockchain system to ensure its safe and stable operation, which is conducive to the popularization of blockchain technology in various industries .

Scenario 2: In many blockchain systems, mining machines are not only used for mining, but also provide specific public services based on business specifics: for example, mining machines based on Proof of Capacity (PoC) will store hard disk storage capacity As computing power, computing power itself is a storage service; another example is a blockchain system that implements mining based on a Trusted Execution Environment (TEE), which can open TEE encryption, decryption, signature, and verification capabilities. Come out and provide security services to the outside world.

In these blockchain systems, a sufficient number of mining machines must be able to ensure the stable operation of the corresponding services. If the blockchain accounting method provided in the present disclosure is used, the base chain can provide sufficient mining machine resources for these blockchain systems to ensure the reliability of the services provided.

In addition, in the blockchain system provided by the present disclosure, the application chain determines the random source that the proposal group and the verification group rely on is provided by the off-chain system (ie the base chain), and the leader of the proposal group is changed to the off-chain system ( That is, the base chain) is implemented, and the off-chain system (ie, the base chain) provides a clock source for the mining process of the application chain. These measures help to strengthen the security of the application chain. A brief analysis of this design is as follows:

The current industry alliance chains generally use the Byzantine consensus algorithm, which limits the number of nodes participating in voting, and requires all nodes to establish connections before voting within a clear number range (for example, the number of nodes in a typical alliance chain Usually limited to about 100, all nodes that make up the alliance chain belong to the proposal group and the verification group, and the proposal group and the verification group are not dynamically formed). The solution of the present disclosure improves on this, and realizes the dynamic selection mechanism of the proposal group and the verification group in the application chain. As mentioned above, the scope of the proposal group or the verification group is determined with the help of the VRF algorithm. However, the inventor found that , The random number (referring to the info in the VRF algorithm) is purely taken as the input of the VRF algorithm in the application chain, and the time factor involved in the process of forming a proposal group or verification group is only used in the application chain (for example, reporting from each node) Time is averaged, etc.) to determine, the security strength is not enough. In order to strengthen the security of the application chain, a random source and a clock source should be provided outside the application chain, which are provided by the base chain in the solution of the present disclosure.

FIG. 3 shows a functional module diagram of the blockchain accounting device 200 provided by the present disclosure. 3, the blockchain accounting device 200 includes:

The proposal group selection module 210 is used for application chain miners to participate in the selection of proposal group members of the application chain to be mined blocks; wherein, if it is determined that the application chain miners are selected as the proposal group members of the application chain to be mined, then The base chain miner sends a mining request for the block to be mined in the application chain, and the proposal group is a collection of application chain miners who have the right to send the mining request;

The block information synchronization module 220 is used for the application chain miners to synchronize the base chain block information, and to incorporate the base chain block information into the local base chain ledger. The base chain block information comes from the base chain miners The base chain block of the leader of the proposal group that determines the block to be mined in the application chain is generated according to the mining request, and the base chain block information includes an election result indicating the leader of the proposal group; wherein, The leader of the proposal group is a member of the proposal group who has the right to produce blocks of the application chain to be mined;

The verification group selection module 230 is used for the application chain miners to participate in the selection of the verification group members of the application chain to be mined blocks; wherein, if it is determined that the application chain miners are selected as the verification group of the application chain to be mined blocks Members, verify the blocks produced by the leader of the proposal group, and broadcast inspection reports to other application chain miners. The verification group is a collection of application chain miners who have the right to generate inspection reports. The proposal group leader The block produced includes the block to be mined in the application chain packaged by the leader of the proposal group;

The application chain accounting module 240 is used for the application chain miners to receive the inspection report, and if it is determined according to the inspection report that the block produced by the proposal group leader is verified, then the block is included in the application chain ledger .

The implementation principles and technical effects of the blockchain accounting device 200 provided in the present disclosure have been introduced in the foregoing method embodiments. For a brief description, for the parts not mentioned in the device embodiments, please refer to the corresponding method embodiments. content.

FIG. 4 shows a functional module diagram of the blockchain accounting device 300 provided by the present disclosure. 4, the blockchain accounting device 300 includes:

The election module 310 is used for base chain miners to elect the leader of the proposal group for the application chain to be mined block according to the mining request sent by the proposal group members of the application chain to be mined block;

The base chain accounting module 320 is used for the base chain miners to incorporate the base chain block storing the election results and the election basis into the base chain ledger.

The implementation principles and technical effects of the blockchain accounting device 300 provided in the present disclosure have been introduced in the foregoing method embodiments. For a brief description, for the parts not mentioned in the device embodiments, please refer to the corresponding method embodiments. content.

FIG. 5 shows a functional module diagram of the blockchain accounting device 400 provided by the present disclosure. 5, the blockchain accounting device 400 includes:

The information receiving module 410 is used for the synchronization node to receive the base chain block sent by the base chain miner to determine the proposal group leader of the application chain to be mined block, or to receive the base chain miner or other set in the base chain The block header of the base chain block and the election result list in the block body of the base chain block sent by the synchronization node; wherein, each entry in the election result list corresponds to an application chain The election result of the leader of the proposal group of the block to be mined, including the election result of the leader of the proposal group of the block to be mined in the application chain;

The information sending module 420 is used for the synchronization node to send the base chain block information derived from the base chain block to the application chain miners, and the form of the base chain block information includes one of the following: the base chain The block itself; the block header of the base chain block and the list of election results in the block body of the base chain block; the block header of the base chain block and the block body of the base chain block Fragment data for the application chain in the application chain; wherein the fragment data includes the election result of the leader of the proposal group for the block to be mined in the application chain in the election result list, and the election result and the The merkle path between merkle roots calculated based on the election result list in the block header of the base chain block.

The implementation principles and technical effects of the blockchain accounting device 400 provided in the present disclosure have been introduced in the foregoing method embodiments. For a brief description, for the parts not mentioned in the device embodiments, please refer to the corresponding method embodiments. content.

Fig. 6 shows a schematic diagram of a blockchain node provided by the present disclosure. 6, the blockchain node 500 includes a processor 510, a memory 520, and a communication interface 530. These components are interconnected and communicate with each other through a communication bus 540 and/or other forms of connection mechanisms (not shown).

Wherein, the memory 520 includes one or more (only one is shown in the figure), which may be, but not limited to, random access memory (Random Access Memory, RAM for short), Read Only Memory (ROM for short) , Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electric Erasable Programmable Read-Only Memory , EEPROM for short) and so on. The processor 510 and other possible components can access the memory 520, read and/or write data therein.

The processor 510 includes one or more (only one is shown in the figure), which may be an integrated circuit chip with signal processing capability. The aforementioned processor 510 may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU for short), a micro controller unit (Micro Controller Unit, MCU for short), a network processor (Network Processor, NP for short), or other conventional processing It can also be a dedicated processor, including Digital Signal Processor (DSP), Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array (FPGA) Or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components.

The communication interface 530 includes one or more (only one is shown in the figure), which can be used to directly or indirectly communicate with other devices to exchange data. For example, the communication interface 530 can be an Ethernet interface; it can be a high-speed network interface (such as an Infiniband network); it can be a mobile communication network interface, such as a 3G, 4G, and 5G network interface; it can be a variety of bus interfaces, such as USB, CAN , I2C, SPI and other bus interfaces; it can also be other types of interfaces with data transceiver functions.

One or more computer program instructions can be stored in the memory 520, and the processor 510 can read and run these computer program instructions to implement the blockchain accounting method provided by the present disclosure and other desired functions.

It can be understood that the structure shown in FIG. 6 is only for illustration, and the blockchain node 500 may also include more or less components than those shown in FIG. 6, or have a different configuration from that shown in FIG. 6. Each component shown in FIG. 6 can be implemented by hardware, software, or a combination thereof. For example, when implemented by hardware, the blockchain node 500 can be a personal computer, mobile phone, tablet computer, server, embedded device, dedicated hardware device for the blockchain system, etc.; when implemented by software, the blockchain node 500 can be a virtual machine, container, etc. In addition, the blockchain node 500 is not limited to a single device, and may also be a combination of multiple devices or a cluster composed of a large number of devices. In the embodiments of the present disclosure, the mining nodes on the base chain, the synchronization nodes on the base chain, the management nodes on the base chain, and the mining nodes on the application chain can all be implemented using the structure of the blockchain node 500 described above. And run their respective functions.

The present disclosure also provides a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are read and run by a processor of the computer, the blockchain record provided by the present disclosure is executed. Accounting method. For example, the computer-readable storage medium may be implemented as the memory 520 in the blockchain node 500 in FIG. 6.

In the embodiments provided in the present disclosure, it should be understood that the disclosed device and method may be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there may be other divisions in actual implementation. For example, multiple units or components may be combined or It can be integrated into another system, or some features can be ignored or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.

In addition, the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

Furthermore, the functional modules in the various embodiments of the present disclosure may be integrated together to form an independent part, or each module may exist alone, or two or more modules may be integrated to form an independent part.

The above are only the embodiments of the present disclosure, and are not used to limit the protection scope of the present disclosure. For those skilled in the art, the present disclosure may have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Industrial applicability

The present disclosure provides a blockchain accounting method, device, node and storage medium. In the solution of the present disclosure, the application chain miners do not directly run the consensus algorithm to compete for the right to produce blocks, but send a mining request to the base chain miners after determining that they are members of the proposal group, and the base chain miners elect the proposal group through calculation The leader records the election results and the basis of the election in the base chain block, and then the application chain miners can obtain the information of the proposal group leader by synchronizing the base chain block information, and then participate in the selection of the verification group members, and pass the collection verification Group members judge whether the block passes the verification according to the inspection report issued by the leader of the proposal group, and if it passes the verification, the account will be kept.

That is, this disclosure proposes a new mechanism for the base chain and the application chain to participate in mining. Under this mechanism, a base chain can gather mining machine resources, provide computing power services for many application chains, and assist the application chain to complete mining. Process, which can effectively improve the waste of mining machine resources in the existing blockchain system, and has good social benefits. In addition, in the solution of the present disclosure, the base chain can provide sufficient mining machine resources for the blockchain system to ensure the safe and stable operation of the newly developed blockchain system, and to ensure that the mining machines in the blockchain system can be externally Provide reliable specific services.

Claims

A blockchain accounting method, characterized in that it is applied to application chain miners, and the method includes:

Participate in the selection of the proposal group members of the application chain to be mined blocks; wherein, if it is determined that the application chain miner is selected as the proposal group member of the application chain to be mined block, then send to the base chain miner that the application chain is to be mined Block mining request, the proposal group is a collection of application chain miners who have the right to send mining requests;

Synchronize the base chain block information, and incorporate the base chain block information into the local base chain ledger. The base chain block information is derived from the information generated by the base chain miners according to the mining request. The base chain block of the leader of the proposal group that mines the block, the base chain block information includes an election result indicating the leader of the proposal group; wherein, the leader of the proposal group has the area to be mined in the application chain Proposal group members with the right to produce blocks;

Participate in the selection of members of the verification group for the block to be mined in the application chain; among them, if it is determined that the miner of the application chain is selected as the member of the verification group of the block to be mined in the application chain, the leader of the proposal group The block is verified, and the inspection report is broadcast to other application chain miners. The verification group is a collection of application chain miners who have the right to generate inspection reports. The block produced by the proposal group leader includes the package packaged by the proposal group leader. The block to be mined in the application chain;

The inspection report is received, and if it is determined that the block produced by the leader of the proposal group is verified according to the inspection report, the block is included in the application chain ledger.
The blockchain accounting method according to claim 1, wherein the determining that the application chain miner is selected as a member of the proposal group of the application chain to be mined block comprises:

Calling the verification function in the verifiable random function VRF algorithm based on the private key of the application chain miner and the first election string determined by the preset rule to obtain the first verifiable string;

A first random value is derived based on the first provable character string, and according to the first random value, it is determined that the application chain miner is selected as a proposal group member of the application chain to be mined block.
The blockchain accounting method according to claim 2, characterized in that the first election string is the Harbin recorded in the block header of the first L block of the base chain block that determines the leader of the proposal group. Hope value or random number, L is a positive integer.
The blockchain accounting method according to claim 2, wherein the determining that the application chain miner is elected as a proposal group member of the application chain to be mined block according to the first random value comprises:

According to the first random value and the weight of the application chain miner’s proposal group participation, it is determined that the application chain miner is selected as the proposal group member of the application chain to be mined; wherein, the application chain miner is selected as the candidate The probability of the members of the proposal group is positively related to the value of the participation weight of the proposal group.
The blockchain accounting method according to claim 4, wherein the application chain miner is selected as the application chain based on the first random value and the proposal group participation weight of the application chain miner. The members of the proposal group of the block to be mined include:

Use the following formula to calculate the second random value RandValue2:

RandValue2=((RandValue1%ExpectedRange1)+priority1)

Wherein, RandValue1 is the first random value, ExpectedRange1 is the preset range value, priority1 is the weight of the proposal group participation, and% represents the remainder operation;

If the following conditions are met, it is determined that the application chain miner is selected as a member of the proposal group for the block to be mined in the application chain:

RandValue2>(ExpectedRange1-(ExpectedRange1*1/M1))

Among them, M1 is the preset filtering ratio.
The blockchain accounting method according to claim 4, wherein the proposal group participation weight is taken as the number of times the application chain miner was elected as the proposal group leader in a preset historical time period.
The blockchain accounting method according to claim 6, wherein the number of times that the application chain miner was elected as the leader of the proposal group in the historical time period is determined from a table constructed based on the base chain block information. Obtained in the query.
The blockchain accounting method according to claim 6, wherein if the application chain miner has not been elected as the leader of the proposal group within the historical time period, the weight of the proposal group participation is 0 , The weight of the proposal group participation is the first accounting weight, and the first accounting weight is a preset non-zero value.
The blockchain accounting method according to claim 6, wherein if the number of times that the application chain miner was elected as the leader of the proposal group in the historical period of time, the proposal group’s right to participate in the proposal group is greater than the preset If the proposal group has the largest participation weight, then the proposal group’s participation weight shall be the maximum participation weight of the proposal group.
The blockchain accounting method according to claim 2, wherein the mining request includes proposal candidate information, and the proposal candidate information includes:

Application chain identification, parallel chain chain number, height of the block to be mined in the application chain, height of the base chain block to determine the leader of the proposal group, public key of the application chain miner, and the first provable string;

Wherein, the application chain identifier refers to the identifier of the application chain where the member of the proposal group that sent the mining request is located, and the parallel chain chain number refers to the member of the proposal group in the parallel chain constituting the application chain The number of the parallel chain where the mining is located, the height of the base chain block of the leader of the proposal group is determined to refer to the height of the base chain block of the leader of the proposal group that determines the block to be mined in the application chain. The chain miner's public key refers to the public key of the proposal group member, and the first provable string refers to the first provable string that the application chain miner relies on when it is elected as a member of the proposal group.
The blockchain accounting method according to claim 1, wherein after determining that the application chain miner is selected as a member of the proposal group of the application chain to be mined, the method further comprises:

The application chain miners selected as members of the proposal group pack the application chain to-be-mined blocks.
The blockchain accounting method according to claim 11, wherein said packaging the application chain to be mined blocks comprises:

Pack the application chain to-be-mined block, and save the proof that the application-chain miner is selected as a member of the proposal group in the first transaction of the application-chain to-be-mined block.
The blockchain accounting method according to claim 11, wherein said packaging the application chain to be mined blocks comprises:

Determine whether the difference between the height of the base chain block of the leader of the proposal group and the height of the block to be mined in the application chain is greater than a preset first difference threshold;

If the difference between the two heights is greater than the first difference threshold, the application chain to be mined blocks and a preset number of empty blocks are continuously packaged; wherein the preset number is not less than one.
The blockchain accounting method according to claim 11, wherein after the packaging of the application chain to be mined blocks, the method further comprises:

Broadcast the application chain to-be-mined block to other application chain miners in the surrounding area.
The blockchain accounting method according to claim 14, wherein the broadcasting the application chain to-be-mined block to other application chain miners in the surrounding area includes:

Specify the number of forwarding times in the broadcast message used to broadcast the block to be mined in the application chain. Each time the block to be mined in the application chain is forwarded, the number of forwarding in the broadcast message is reduced by 1, and the number of forwarding is When it is reduced to 0, stop broadcasting the application chain to-be-mined block.
The blockchain accounting method according to claim 1, wherein the base chain is composed of at least one parallel chain, and the base chain miner sends a mining request for the block to be mined in the application chain to the base chain miner, include:

Send a mining request for a block to be mined in the application chain to a base chain miner on one of the at least one parallel chain of the base chain.
The blockchain accounting method according to claim 16, characterized in that, said base chain miners on one of the at least one parallel chain of the base chain are sent to the base chain miners on the application chain to be mined. The mining request includes:

Determine a parallel chain from at least one parallel chain of the base chain according to the following formula, and send a mining request for the block to be mined in the application chain to the base chain miners on the parallel chain:

n=(ChainNoOffet+k)%N

Wherein, N is the total number of parallel chains of the base chain, N is a positive integer, and the N parallel chains of the base chain are sequentially numbered from 0 to N-1, and ChainNoOffet is the chain number preset by the application chain Offset, k is the chain number of the parallel chain where the members of the proposal group mine in the parallel chain constituting the application chain,% represents the remainder operation, and n represents the determined parallel chain number of the base chain.
The blockchain accounting method according to claim 1, wherein the synchronization base chain block information includes:

Synchronize the block information of the base chain from the synchronization node set in the base chain.
The blockchain accounting method according to claim 1, wherein the form of the base chain block information includes one of the following:

Determine the base chain block itself of the leader of the proposal group;

The block header of the base chain block and the election result list in the block body of the base chain block, each entry in the election result list corresponds to the election of a block to be mined on an application chain The result includes the election result of the leader of the proposal group of the block to be mined in the application chain;

The block header of the base chain block and the fragment data for the application chain in the block body of the base chain block; wherein the fragment data includes the list of election results for the application chain to be mined The election result of the leader of the proposal group of the block, and the merkle path between the election result and the merkle root calculated based on the election result list in the block header of the base chain block.
The blockchain accounting method according to claim 1, wherein the selection of the verification group members of the application chain to be mined blocks is divided into at least one round;

When the application chain miners synchronize to the base chain block information of the leader of the proposal group that determines the block to be mined in the application chain, they participate in the selection of the members of the previous P round verification group. After that, the application chain miners synchronize to one Base chain block information will participate in the new round of selection of members of the verification team. Unless one of the following conditions is met, it will no longer participate in the new round of selection of members of the verification team:

The application chain miner determines that he is elected as a member of the verification group in the selection rounds that he has participated in;

The application chain miner can draw a conclusion that the block verification passed by the leader of the proposal group according to the currently received inspection report;

The selection rounds that the application chain miners have participated in have reached the preset maximum round;

Among them, 1≤P≤MaxRounds, and MaxRounds is the maximum round. If the application chain miner determines that he is elected as a member of the verification group in the election rounds that he has participated in, the leader of the proposal group will be Block verification and broadcast inspection reports to other application chain miners.
The blockchain accounting method according to claim 1, wherein the determining that the application chain miner is selected as a verification group member of the application chain to be mined block comprises:

Call the proof function in the VRF algorithm based on the private key of the application chain miner and the second election string determined by the preset rules to obtain the second provable string;

Derive a third random value based on the second provable string, and determine that the application chain miner is selected as the application chain to be mined according to the third random value and the verification group participation weight of the application chain miner A member of the verification group of the block; wherein the probability of the application chain miner being selected as a member of the verification group is positively related to the value of the weight of the verification group participation.
The blockchain accounting method according to claim 21, wherein the verification group participation weight is calculated according to the amount of digital currency currently held by the application chain miner, and if the application chain miner does not currently hold If there is digital currency, the weight of the verification group participation is 0.
The blockchain accounting method according to claim 22, wherein if the amount of digital currency currently held by the application chain miners makes the verification group participation weight greater than the preset maximum verification group participation weight, Then the verification group participation weight takes the maximum verification group participation weight.
The blockchain accounting method according to claim 22, wherein if the amount of digital currency currently held by the application chain miners is less than the preset minimum amount of currency holdings, the application chain miners do not participate in the verification group Selection of members.
The blockchain accounting method according to claim 21, wherein the selection of the verification group members of the application chain to be mined block is divided into at least one round, and the second election string is calculated according to the following information:

The miner identification of the leader of the proposal group, the height of the base chain block that determines the leader of the proposal group, the height of the block to be mined in the application chain, and the round number for selecting the members of the verification group.
The blockchain accounting method according to claim 1, wherein when the leader of the proposal group broadcasts the block, it also broadcasts the mining of the block sent by the leader of the proposal group. For the proposal candidate information in the request, the application chain miners who are selected as members of the verification group of the application chain to be mined block verify the block produced by the proposal group leader, including the following verification items:

According to the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, the first election string that the proposal group leader relies on when elected as a member of the proposal group is determined, based on the proposal candidate information The first provable string in the proposal candidate information, the application chain miner public key in the proposal candidate information, and the first election string call the verification function in the VRF algorithm to verify the first provable string in the proposal candidate information Whether it has been forged;

Verifying whether the application chain miner corresponding to the application chain miner public key in the proposal candidate information is the creator of the block produced by the proposal group leader;

According to the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, query the proposal group leader from the local base chain ledger, and verify the inquired proposal group leader and the proposal candidate Whether the leaders of the proposal group determined by the information are consistent;

Verify that all transactions in the block produced by the leader of the proposal group are correct;

If the verification results of all verification items are "Yes", the generated inspection conclusion is an inspection report that has passed the verification, otherwise, the generated inspection conclusion is an inspection report that has not passed the verification.
The blockchain accounting method according to claim 26, wherein the block header of the block produced by the leader of the proposal group stores public key information that characterizes the identity of the block creator, and the verification of the Whether the application chain miner corresponding to the application chain miner public key in the proposal candidate information is the creator of the block produced by the proposal group leader includes:

Verify whether the public key information obtained from the application chain miner public key in the proposal candidate information is consistent with the public key information stored in the block header, and if they are consistent, confirm the application chain miner public key in the proposal candidate information The corresponding application chain miner is the creator of the block produced by the proposal group leader, otherwise the application chain miner is not the creator of the block produced by the proposal group leader.
The blockchain accounting method according to claim 26, characterized in that, when the leader of the proposal group broadcasts the output block, the leader of the proposal group also broadcasts that the leader of the proposal group uses its own private key to verify the output of the block. The signature of the block to verify whether the application chain miner corresponding to the application chain miner public key in the proposal candidate information is the creator of the block produced by the proposal group leader includes:

Use the public key of the application chain miner in the proposal candidate information to verify whether the signature of the block produced by the leader of the proposal group carried in the broadcast message is correct, and if it is correct, confirm the application chain miner in the proposal candidate information The application chain miner corresponding to the public key is the creator of the block produced by the proposal group leader, otherwise the application chain miner is not the creator of the block produced by the proposal group leader.
The blockchain accounting method according to claim 26, characterized in that, according to the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, the local base chain ledger is queried for the The leader of the proposal group, verifying whether the queried leader of the proposal group is consistent with the leader of the proposal group determined by the proposal candidate information, including:

According to the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, the public key of the proposal group leader is queried from the local base chain ledger, and the public key of the queried proposal group leader is verified. Whether the key is consistent with the public key of the application chain miner in the proposal candidate information, if they are the same, confirm that the queried leader of the proposal group is consistent with the leader of the proposal group determined by the proposal candidate information, otherwise two Leaders of the proposal group are inconsistent;

or,

According to the height of the base chain block that determines the leader of the proposal group in the proposal candidate information, the local base chain ledger is queried for the miner ID of the proposal group leader, and based on the application chain miner company in the proposal candidate information Key, the application chain identifier in the proposal candidate information and the parallel chain chain number in the proposal candidate information, the hash algorithm is used to calculate the miner ID of the leader of the proposal group, and the queried leader of the proposal group is verified Whether the human miner ID is consistent with the calculated miner ID of the proposal group leader, if they are the same, confirm that the queried proposal group leader is consistent with the proposal group leader determined by the proposal candidate information, Otherwise, the leaders of the two proposal groups are inconsistent.
The blockchain accounting method according to claim 1, wherein said determining, according to the inspection report, that the block produced by the leader of the proposal group has been verified, comprises:

If the number of passed inspection reports in the received inspection report is not less than the minimum number of successful verifications, and the number of failed inspection reports is not greater than the maximum number of failed verifications, it is determined that the block verification by the leader of the proposal group is passed ；

Wherein, the minimum number of successful verifications and the maximum number of failed verifications are preset values, or calculated based on the number of application chain miners selected as the leader of the proposal group within a preset time period.
The blockchain accounting method according to claim 1, wherein said determining, according to the inspection report, that the block produced by the leader of the proposal group has been verified, comprises:

Determine the number of votes of the received inspection report during the verification process. The number of votes for each inspection report is positively related to the amount of digital currency currently held by the verification team member who generated the inspection report;

If the total number of votes in the received inspection report is not less than the minimum number of successful verifications, and the total number of votes in the failed inspection reports is not greater than the maximum number of failed verifications, the leader of the proposal group is determined The block verification passed.
The blockchain accounting method according to claim 31, wherein said determining the number of votes in the verification process of the received inspection report comprises:

Determine the number of votes in the verification process of the received inspection report according to the following formula:

vote_num=1+stake/leverage

Wherein, vote_num is the number of votes occupied by the inspection report, stake is the amount of digital currency currently held by the verification group members that generated the inspection report, and leverage is the preset vote adjustment ratio.
The blockchain accounting method of claim 30, wherein the method further comprises:

If the proportion of the number of reports passed in the received inspection report to the minimum number of successful verifications is not less than the preset verified proportion, the selection of the proposal group members for the next application chain block to be mined is started in advance.
The blockchain accounting method according to claim 1, wherein the inspection report includes the following information:

The miner identification of the leader of the proposal group, the height of the base chain block that determines the leader of the proposal group, the height of the block to be mined in the application chain, the round number of the selection verification group member, the public key of the verification group member who generated the inspection report, The second provable string that the app chain miners rely on when they are selected as members of the verification group, the hash value of the block to be mined in the app chain, the verification conclusion, and the signature of the verification report using the private key of the verification group member.
The blockchain accounting method according to claim 34, characterized in that, before the application chain miner approves the inspection conclusion in the inspection report, the method further comprises:

Use the public key of the verification group member in the inspection report to confirm that the signature in the report is correct;

According to the height of the base chain block that determines the leader of the proposal group in the inspection report, query the leader of the proposal group from the local base chain ledger, and confirm that the inquired leader of the proposal group and the inspection report office The determined leaders of the proposal group are consistent;

The inspection is calculated and generated according to the miner identification of the leader of the proposal group in the inspection report, the height of the base chain block that determines the leader of the proposal group, the height of the block to be mined in the application chain, and the round number of the selected verification group member The second election string on which the reported application chain miners were elected as members of the verification group is based on the second election string, the public key of the verification group member who generated the verification report in the verification report, and the The second provable string in the inspection report calls the verification function in the VRF algorithm to confirm that the second provable string in the inspection report is not forged;

A third random value is derived based on the second provable character string in the inspection report, and the application chain miner who generated the inspection report is confirmed as a member of the verification group according to the third random value.
The block chain accounting method according to claim 35, wherein the proposal is inquired from the local base chain ledger according to the height of the base chain block that determines the leader of the proposal group in the inspection report The group leader, confirming that the inquired leader of the proposal group is consistent with the leader of the proposal group determined in the inspection report, including:

According to the height of the base chain block determining the leader of the proposal group in the inspection report, query the public key of the leader of the proposal group from the local base chain ledger, based on the public key of the leader of the proposal group found out , The application chain identifier and the parallel chain chain number where the application chain miner is mining, the hash algorithm is used to calculate the miner identifier of the proposal group leader, and the calculated miner identifier of the proposal group leader is confirmed with the The miner's identification of the leader of the proposal group in the inspection report is consistent;

or,

According to the height of the base chain block determining the leader of the proposal group in the inspection report, query the local base chain ledger for the miner ID of the proposal group leader, and confirm the miner ID of the leader of the proposal group that was queried It is consistent with the miner identification of the leader of the proposal group in the inspection report.
The blockchain accounting method according to claim 1, wherein the method further comprises:

If it is determined according to the inspection report that the block produced by the leader of the proposal group has passed the verification, the selection of the proposal group members of the block to be mined in the next application chain is started;

If it is determined according to the inspection report that the block produced by the leader of the proposal group is not verified, the block produced by the leader of the proposal group is discarded, and if other blocks are connected in series after the block, then discarded together And restart the selection of the members of the proposal group for the block to be mined in the application chain.
The blockchain accounting method according to claim 20, wherein P>1, if it is determined according to the inspection report that the block produced by the leader of the proposal group is verified, then the block is included The application chain ledger includes:

If it is determined according to the inspection report that the block produced by the leader of the proposal group has been verified, and the inspection reports that have passed the conclusion are all valid, the block is included in the application chain ledger; The inspection report becomes effective after the application chain miner synchronizes to the base chain block information corresponding to the report generation round. The report generation round refers to the selection round in which the application chain miner who generated the inspection report is elected as a member of the verification group Times.
The blockchain accounting method of claim 20, wherein the method further comprises:

From the time the miners of the application chain are synchronized to the base chain block information of the proposal group leader who determines the block to be mined in the application chain, MaxRounds+Q base chain block generation time, continue to receive the proposal group leader The inspection report of the exit zone, and maintain or change the previous conclusion that the leader of the proposal group has passed the verification based on the newly received inspection report;

Wherein, the application chain miner allows at most the latest Q+1 blocks including the block to be mined in the application chain to be in the verification state at the same time, and Q takes 0 or a positive integer.
The blockchain accounting method according to claim 1, wherein the method further comprises:

When it is determined that there is a new proposal group leader different from the old proposal group leader for the application chain block with the highest height in the application chain ledger, it is determined whether the priority of the new proposal group leader is higher than the old proposal group leader. The priority of the leader of the proposal group;

If the priority of the leader of the new proposal group is higher than the priority of the leader of the old proposal group, then the application chain ledger that is located on the current main branch and created by the old proposal group leader The application chain block of the first height is switched to the application chain block of the first height created by the leader of the new proposal group.
The blockchain accounting method of claim 40, wherein the difference between the first height and the maximum block height in the application chain ledger is less than a preset height difference.
The blockchain accounting method according to claim 40, characterized in that it is determined that there is a new proposal group leader different from the old proposal group leader for the application chain block of the first height in the application chain ledger Including at least one of the following:

When receiving the application chain block of the first height broadcast by other application chain miners, according to the proposal candidate information recorded in the block or the proposal candidate information broadcasted with the block, it is determined that the first height is There is a new proposal group leader different from the old proposal group leader in the application chain block;

According to the synchronized base chain block information, it is determined that there is a new proposal group leader different from the old proposal group leader for the application chain block of the first height.
The blockchain accounting method according to claim 40, characterized in that, in the application chain ledger, the first height created by the leader of the old proposal group is located on the current main branch. Before the application chain block of is switched to the application chain block of the first height created by the leader of the new proposal group, the method further includes:

Receive the first-level application chain block created by the leader of the new proposal group broadcasted by other application chain miners, or search locally cached application chain blocks created by the leader of the new proposal group The application chain block of the first height.
The blockchain accounting method according to any one of claims 40-43, wherein the determining whether the priority of the leader of the new proposal group is higher than the priority of the leader of the old proposal group ,include:

Acquiring the second random value used when the new proposal leader is selected as a member of the proposal group, and the second random value used when the old proposal leader is selected as a member of the proposal group;

Judging whether the second random value corresponding to the new proposal leader is greater than the second random value corresponding to the old proposal leader;

Wherein, if the second random value corresponding to the new proposal leader is greater than the second random value corresponding to the old proposal leader, it is determined that the priority of the leader of the new proposal group is higher than the leader of the old proposal group Otherwise, it is determined that the priority of the leader of the new proposal group is not higher than the priority of the leader of the old proposal group.
A blockchain accounting method, characterized in that it is applied to base chain miners, and the method includes:

Electing the leader of the proposal group for the application chain to be mined block according to the mining request sent by the proposal group member of the application chain to be mined block;

Incorporate the base chain block holding the election results and the basis of the election into the base chain ledger.
The blockchain accounting method of claim 45, wherein the mining request includes proposal candidate information, and the proposal candidate information includes:

Application chain identification, parallel chain chain number, height of the block to be mined in the application chain, height of the base chain block to determine the leader of the proposal group, public key of the application chain miner, and the first provable string.
The blockchain accounting method according to claim 46, wherein the mining request for the application chain to be mined block sent by the proposal group member according to the application chain to be mined block is the Before electing the leader of the proposal group for the block to be mined in the application chain, the method further includes:

Determine, according to the application chain identifier in the mining request, that the application chain corresponding to the identifier is supported by the base chain with computing power;

According to the height of the base chain block that determines the leader of the proposal group in the mining request, it is determined that the application chain miner who sent the mining request is selected as the first election string that the proposal group member relies on, based on the mining The application chain miner's public key in the mining request, the first proof string in the mining request, and the first election string call the verification function in the VRF algorithm to determine the first provable in the mining request The string has not been forged.
The blockchain accounting method according to claim 46, wherein the mining request for the application chain to be mined block sent by the proposal group member according to the application chain to be mined block is the Before electing the leader of the proposal group for the block to be mined in the application chain, the method further includes:

According to the application chain identifier, the parallel chain chain number, and the application chain miner public key in the mining request, a hash algorithm is used to calculate the miner identifier of the proposal group member who sent the mining request;

It is determined that the calculated miner ID is not in the blacklist configured by the base chain for the application chain.
The blockchain accounting method of claim 47, wherein the method further comprises:

Obtain authorization and configuration information from the management node set in the base chain; wherein, the authorization information includes information about the application chain that has been registered with the management node to obtain the computing power support of the base chain, and the configuration information includes all The preset parameters used by the base chain miners are described.
The blockchain accounting method according to claim 49, wherein the obtaining authorization and configuration information from the management node set in the base chain comprises:

At the beginning of the difficulty adjustment period of the base chain, the management node set in the base chain is inquired about whether the locally stored authorization and configuration information is the latest version. If it is not the latest version, the latest version of the authorization and configuration information will be synchronized from the management node. Configuration information; among them, a query is performed every preset number of difficulty adjustment cycles.
The blockchain accounting method according to claim 46, wherein the mining request for the application chain to be mined block sent according to the proposal group member of the application chain to be mined block is the application The leader of the proposal group for the block to be mined on the chain, including:

Determine the new height of the application chain to be mined according to the highest block of the application chain recorded in the base chain ledger and the leader of the proposal group has been selected, and compare the height of the application chain to be mined block contained in it with the total The mining request consistent with the new height is included in the waiting set for the new height;

If the number of requests in the set to be elected for the new height is not less than the preset minimum number of miners, then according to the first provable word in each mining request in the set to be elected for the new height String to determine the leader of the proposal group of the block at the new height of the application chain.
The blockchain accounting method according to claim 51, characterized in that the highest block of the application chain recorded in the base chain ledger and the leader of the proposal group has been selected is used to determine the application chain to-be-mined area After the new height of the block, the method further includes:

Judging whether the difference between the height of the base chain block of the leader of the proposal group of the block to be mined in the application chain and the new height is greater than a preset first difference threshold;

If the difference between the two heights is greater than the first difference threshold, mark the application chain to continuously generate blocks at the new height.
The blockchain accounting method according to claim 52, wherein the method further comprises:

If the difference between the two heights is greater than the preset second difference threshold, refuse to continue to provide computing power support for the application chain; wherein the second difference threshold is greater than the first difference threshold.
The blockchain accounting method of claim 51, wherein the application is determined according to the first provable string in each mining request in the set to be elected for the new height The leader of the proposal group of the block with the chain at the new height, including:

Calculate the second random value corresponding to the mining request according to the first provable string in each mining request in the set to be elected for the new height, and the calculated second random value meets the preset The proposal group member corresponding to the selected mining request is determined as the proposal group leader of the block of the application chain at the new height.
The blockchain accounting method according to claim 54, characterized in that, the election condition is that the calculated second random value is the largest.
The blockchain accounting method of claim 55, wherein the selection condition is that the calculated second random value is the largest and the second random value is greater than a preset minimum random value.
The blockchain accounting method of claim 55, wherein the method further comprises:

If the application chain is configured to disallow continuous mining by the same miner, and the proposal group leader determined according to the largest second random value is also selected as a proposal in the last proposal group leader election for the application chain The group leader determines the proposal group member corresponding to the mining request with the second largest random value calculated as the proposal group leader of the block of the application chain at the new height.
The blockchain accounting method according to claim 51 or 56, wherein the method further comprises:

If the leader of the proposal group that elects the block of the new height according to the mining request in the set of to-be-elected for the new height fails, obtain the block adjacent to the application chain to be mined in the application chain And the old height of the block of the leader of the proposal group has been selected, and the mining request whose height of the application chain to be mined block contained in it is consistent with the old height is included in the set to be elected for the old height;

According to the mining request in the set to be elected for the old height, re-elect the leader of the proposal group of the application chain in the block of the old height. If the election is successful, then in the area where the base chain has exited this time The election result and election basis are stored in the block. If the election fails, continue to collect mining requests and elect the proposal group leader's re-mining operation for the previous old height, until the old height election proposal group for the application chain The leader succeeds or the re-mining operation for the old height of the application chain reaches the preset limit of times;

If the re-mining operation for the old height of the application chain has reached the preset number limit but the proposal group leader has not been successfully selected, the next time the base chain generates a block, the application chain will be re-mined in the A new level of block election proposal group leader.
The blockchain accounting method according to claim 51, wherein the election result includes proposal candidate information obtained from a mining request sent by the leader of the proposal group of the application chain;

The election result is stored in the block body of the base chain block as an entry in the election result list, and each entry in the election result list corresponds to a block to be mined on an application chain. Election result

The merkle root calculated based on the entries of the election result list is stored in the block header of the base chain block.
The blockchain accounting method according to claim 51, wherein the election result includes the miner identification of the leader of the proposal group and the height of the block to be mined in the application chain;

The miner ID of the proposal group leader is calculated based on the application chain ID, the parallel chain chain number, and the application chain miner’s public key in the mining request sent by the proposal group leader, and the application chain is waiting The height of the mining block is copied from the corresponding information item in the mining request sent by the leader of the proposal group;

The election result is stored in the block body of the base chain block as an entry in the election result list, and each entry in the election result list corresponds to a block to be mined on an application chain. Election result

The merkle root calculated based on the entries of the election result list is stored in the block header of the base chain block.
The blockchain accounting method according to claim 59 or 60, wherein the election basis comprises a set of proposal candidate information obtained from mining requests in the set to be elected for the new height;

The election basis is stored in the block body of the base chain block as an entry in the election basis list, and each entry in the election basis list corresponds to a block to be mined on an application chain. Election basis

The merkle root calculated based on the entries of the election basis list is stored in the block header of the base chain block.
The blockchain accounting method according to claim 61, wherein the method further comprises:

Sending the base chain block to a synchronization node set in the base chain;

Or, sending the block header of the base chain block and the election result list in the block body of the base chain block to the synchronization node.
The blockchain accounting method according to claim 61, wherein the blocks in the base chain ledger are stored in the following manner:

The blocks generated in the last D difficulty adjustment cycles of the base chain save the block header and the block body; where D is a positive integer;

Blocks generated before the most recent D difficulty adjustment cycles of the base chain save the block header and the election result list. If the entry of the election result list contains the miner identification of the leader of the proposal group, the election basis shall also be saved Proposal candidate information generated by the leader of the proposal group in the list.
A blockchain accounting method, characterized in that it is applied to a synchronization node set in a base chain, and the method includes:

Receive the base chain block of the leader of the proposal group sent by the base chain miner to determine the block to be mined in the application chain, or receive the base chain block sent by the base chain miner or other synchronization nodes set in the base chain The block header and the election result list in the block body of the base chain block; wherein, each entry in the election result list corresponds to the election of the leader of the proposal group of a block to be mined on the application chain The result includes the election result of the leader of the proposal group of the block to be mined in the application chain;

Send the base chain block information derived from the base chain block to the application chain miner, and the form of the base chain block information includes one of the following:

The base chain block itself;

The block header of the base chain block and the election result list in the block body of the base chain block;

The block header of the base chain block and the fragment data for the application chain in the block body of the base chain block; wherein the fragment data includes the list of election results for the application chain to be mined The election result of the leader of the proposal group of the block, and the merkle path between the election result and the merkle root calculated based on the election result list in the block header of the base chain block.
The blockchain accounting method according to claim 64, wherein the method further comprises:

Send the block header of the base chain block and the election result list in the block body of the base chain block to other synchronization nodes set in the base chain.
A blockchain accounting device, characterized in that it is configured on a mining node set in an application chain, and the device includes:

The proposal group selection module is used for application chain miners to participate in the selection of proposal group members of the application chain to be mined blocks; among them, if it is determined that the application chain miner is selected as the proposal group member of the application chain to be mined, then A chain miner sends a mining request for a block to be mined in the application chain, and the proposal group is a collection of application chain miners who have the right to send a mining request;

The block information synchronization module is used for the application chain miners to synchronize the base chain block information and incorporate the base chain block information into the local base chain ledger. The base chain block information comes from the base chain miners according to The mining request generates the base chain block of the leader of the proposal group that determines the block to be mined in the application chain, and the base chain block information includes an election result indicating the leader of the proposal group; The leader of the proposal group is a member of the proposal group who has the right to produce blocks of the application chain to be mined;

The verification group selection module is used for the application chain miners to participate in the selection of the verification group members of the application chain to be mined blocks; wherein, if it is determined that the application chain miners are selected as the verification group members of the application chain to be mined blocks , Verify the block produced by the leader of the proposal group, and broadcast the inspection report to other application chain miners. The verification group is a collection of application chain miners who have the right to generate inspection reports. The output block includes the block to be mined in the application chain packaged by the leader of the proposal group;

The application chain accounting module is used for the application chain miner to receive the inspection report, and if it is determined according to the inspection report that the block produced by the proposal group leader is verified, the block is included in the application chain ledger.
A blockchain accounting device, characterized in that it is configured on a mining node set in the base chain, and the device includes:

Election module, used for base chain miners to elect the leader of the proposal group for the application chain to be mined block according to the mining request sent by the proposal group members of the application chain to be mined block;

The base chain accounting module is used for the base chain miners to incorporate the base chain block storing the election results and the election basis into the base chain ledger.
A blockchain accounting device, characterized in that it is configured on a synchronization node set in a base chain, and the device includes:

The information receiving module is used for the synchronization node to receive the base chain block sent by the base chain miner to determine the proposal group leader of the application chain to be mined block, or to receive the base chain miner or other synchronization set in the base chain The block header of the base chain block and the election result list in the block body of the base chain block sent by the node; wherein, each entry in the election result list corresponds to a waiting list on an application chain. The election result of the leader of the proposal group for mining the block, including the election result of the leader of the proposal group for the block to be mined in the application chain;

The information sending module is used for the synchronization node to send the base chain block information derived from the base chain block to the application chain miners, and the form of the base chain block information includes one of the following:

The base chain block itself;

The block header of the base chain block and the election result list in the block body of the base chain block;

The block header of the base chain block and the fragment data for the application chain in the block body of the base chain block; wherein the fragment data includes the list of election results for the application chain to be mined The election result of the leader of the proposal group of the block, and the merkle path between the election result and the merkle root calculated based on the election result list in the block header of the base chain block.
A blockchain node, characterized in that it is set on an application chain, the node includes: a memory and a processor, and computer program instructions are stored in the memory, and the computer program instructions are read and combined by the processor. When running, the method according to any one of claims 1-44 is executed.
A blockchain node, characterized in that it is set on a base chain, the node includes: a memory and a processor, and computer program instructions are stored in the memory, and the computer program instructions are read and combined by the processor. At runtime, the method according to any one of claims 45-63 is executed.
A blockchain node, characterized in that it is set on a base chain, the node includes: a memory and a processor, and computer program instructions are stored in the memory, and the computer program instructions are read and combined by the processor. At runtime, the method according to claim 64 or 65 is executed.
A computer-readable storage medium, characterized in that computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are run by a computer, the computer program instructions as described in any one of claims 1-65 are executed. method.