Block chain consensus method and device with optimized bandwidth and electronic equipment

A bandwidth-optimized blockchain consensus method, device and technical field of electronic equipment

[0001] This application relates to the field of network technology, and in particular to a bandwidth-optimized blockchain consensus method, device, and electronic equipment.

Background technique

[0002] Blockchain is a new distributed technology, which is a new application mode of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. The network adopting the blockchain technology architecture can be regarded as a blockchain network. The blockchain network contains multiple blockchain nodes. Any blockchain node can correspond to at least one blockchain, and any blockchain can correspond to at least one blockchain. Contains at least one block.

[0003] In the blockchain technology, the consensus algorithm is an important method for establishing trust between different blockchain nodes in the blockchain network and obtaining rights and interests. At present, in blockchains that adopt consensus algorithms such as Byzantine Fault Tolerance (BFT), the underlying platform of the blockchain first completes a consensus on the transaction, and then completes the execution calculation of the transaction after the consensus is completed. In this type of consensus algorithm, multiple rounds of voting are generally used. In the process of multiple rounds of voting, due to network and other reasons, although all consensus nodes have received more than 2/3 of the pre-submission votes for a proposal, each The pre-commit votes that a consensus node may receive are different. Therefore, consensus is also required for pre-voting over a certain percentage of proposals that are successful in consensus. In the current consensus method, most of the data of all pre-commit results are packaged into a consensus proof, and the proposed nodes in the next round are submitted together for a new round of consensus. This leads to a waste of bandwidth resources.

[0004] Therefore, there is an urgent need to find a blockchain consensus solution for optimizing bandwidth in the blockchain to overcome the above-mentioned problems.

Summary of the invention

[0005] The embodiments of the present application provide a bandwidth-optimized blockchain consensus method, device, and electronic equipment to solve the problem of bandwidth resource waste in the Byzantine fault tolerance consensus algorithm in the prior art.

[0006] In order to solve the above technical problems, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, a bandwidth-optimized blockchain consensus method is provided, which is applied to a blockchain network including multiple blockchain nodes, and the method includes:

[0008] Each consensus node in the blockchain network receives the proposal and pre-votes;

[0009] Each consensus node receives pre-voting results sent by other consensus nodes in the blockchain network;

[0010] Each consensus node judges the received pre-voting result and generates a pre-commit result;

[0011] Broadcast the pre-submission result;

[0012] Each consensus node judges the pre-commit result, and packages the pre-commit result of the consensus proposal into a consensus proof;

[0013] The next high-level proposal node submits a proposal and the consensus proof;

[0014] Perform the next round of consensus on the proposal and the consensus proof.

[0015] Optionally, each consensus node judges the pre-commit result, and packs the pre-commit result of the consensus proposal into a consensus proof, including:

[0016] The pre-commit result received by each consensus node is consistent with all consensus nodes in the blockchain network

The ratio of points is greater than or equal to the first threshold, and the pre-commit results of the consensus proposal are packaged into a consensus proof.

[0017] In a possible implementation, each consensus node judges the received pre-voting and generates a pre-commit result, including:

[0018] The ratio of the pre-voting result received by each consensus node to all consensus nodes in the blockchain network is greater than or equal to a second threshold, and the pre-commit result is generated.

[0019] Optionally, the first threshold is 2/3.

[0020] Optionally, the second threshold is 2/3.

[0021] In a second aspect, a bandwidth-optimized blockchain consensus device is provided, which is applied to a blockchain network including multiple blockchain nodes, and the device includes:

[0022] The transceiver module is used for each consensus node in the blockchain network to receive proposals and receive pre-voting results sent by other consensus nodes in the blockchain network;

[0023] The processing module is used for each consensus node in the blockchain network to pre-vote according to the proposal, and to judge the pre-voting result received by the transceiver module, according to the pre-voting received by the transceiver module Voting results generate pre-submission results;

[0024] The transceiver module is also used to broadcast the pre-submission result;

[0025] The processing module is also used for each consensus node to judge the pre-commit result, and package the pre-commit result of the consensus proposal into a consensus proof; the next high-level proposal node submits the proposal and the result The consensus proof; the proposal and the consensus proof are carried out to the next round of consensus.

[0026] In a possible implementation, the processing module is specifically used for the ratio of the pre-commit result received by the transceiver module to all consensus nodes in the blockchain network is greater than or equal to the first A threshold is used to package the pre-commit results of the consensus proposal into a consensus proof.

[0027] In a possible implementation, the processing module is specifically used for the ratio of the pre-voting result received by the transceiver module to all consensus nodes in the blockchain network is greater than or equal to a second threshold To generate the pre-submission result.

[0028] In a third aspect, an electronic device is provided, including: a memory, a processor, and a computer program stored on the memory and running on the processor, the computer program being executed by the processor The method described in the first aspect or any implementation manner of the first aspect.

[0029] In a fourth aspect, a computer storage medium is provided, including instructions for causing a computer to execute the method described in the first aspect or any one of the implementation manners of the first aspect.

[0030] In a fifth aspect, the present application provides a chip that is connected to a memory and is used to read and execute a software program stored in the memory to implement the first aspect or any implementation manner of the first aspect The method described.

[0031] The above-mentioned at least one technical solution adopted in the embodiments of the present application can achieve the following beneficial effects:

[0032] The technical solutions provided in the embodiments of the present application have a consensus on the success of a proposal. A certain percentage of pre-voting and a certain percentage of pre-submissions must be reached or exceeded before a consensus can be reached. The consensus certificate only contains The pre-submission of the consensus-successful proposal effectively optimizes bandwidth resources, avoids the waste of bandwidth resources, and improves bandwidth utilization.

Description of the drawings

[0033] In order to more clearly describe the technical solutions in this embodiment or the prior art, the following will describe the embodiments or

The drawings that need to be used in the description of the prior art are briefly introduced. Obviously, the drawings in the following description are only some of the embodiments recorded in this embodiment. For those of ordinary skill in the art, they would not be creative. Under the premise of labor, other drawings can be obtained based on these drawings.

[0034] FIG. 1 is a schematic diagram of a blockchain consensus algorithm provided by an embodiment of the application;

[0035] FIG. 2 is a schematic diagram of another blockchain consensus algorithm provided by an embodiment of the application;

[0036] FIG. 3 is a flowchart of a bandwidth-optimized blockchain consensus method provided by an embodiment of the application;

[0037] FIG. 4 is a schematic structural diagram of an electronic device provided by an embodiment of the application;

[0038] FIG. 5 is a schematic structural diagram of a bandwidth-optimized blockchain consensus device provided by an embodiment of the application.

Detailed ways

[0039] In order to make the objectives, technical solutions, and advantages of this embodiment clearer, the technical solution of this embodiment will be described clearly and completely below in conjunction with this specific embodiment and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by a person of ordinary skill in the art without creative work shall fall within the protection scope of the embodiments of this specification.

[0040] The following describes in detail the technical solutions provided by the embodiments in conjunction with the accompanying drawings.

[0041] The blockchain is essentially a decentralized database, which is a series of associated data blocks generated using cryptographic methods, and each data block contains information about transactions on the entire network within a period of time. Different blockchains have different connotations and functions. The most important thing in the blockchain is the consensus algorithm. The consensus algorithm includes distributed consensus algorithms. Distributed consensus algorithms can generally be divided into BFT algorithms and non-BFT algorithms. The current mainstream Byzantine fault tolerance algorithms include the traditional Practical Byzantine Fault Tolerance (PBFT) algorithm, tendermint algorithm and so on.

[0042] Based on the Byzantine General's problem, the consistency of the assurance is mainly divided into three stages: pre-preparation (pre prepare), preparation (prepare) and confirmation (commit). The schematic diagram is shown in Figure 1.

[0043] In FIG. 1, C is the sending request end node, 0, 1, 2, and 3 are the server end nodes, and 3 is the down server node. The specific steps are as follows:

[0044] Request: The request end node C sends a request to any node, which is 0 in the embodiment of the present application.

[0045] Pre-Prepare (Pre-Prepare): the server node 0 broadcasts after receiving the request of node C, and spreads to nodes 1, 2, 3.

[0046] Preparation (Prepare): Nodes 1, 2, and 3 record and broadcast again after receiving the broadcast of node 0. Node 1 broadcasts to nodes 0, 2, and 3, node 2 broadcasts to nodes 0, 1, and 3, and node 3 cannot broadcast because of downtime.

[0047] Commit: Nodes 0, 1, 2, and 3 are in the preparation phase, and if they receive more than a certain number of identical requests, they enter the confirmation phase and broadcast the confirmation request.

[0048] Reply (Reply): Nodes 0, 1, 2, and 3 are in the confirmation phase, and if they receive more than a certain number of identical requests, they will give feedback to node C.

[0049] It can be seen that the PBFT consensus algorithm is actually a state machine copy replication algorithm, that is, the service is modeled as a state machine, and the state machine performs copy replication at different nodes of the distributed system. Each copy of the state machine saves the state of the service and also implements the operation of the service.

[0050] The tendermint algorithm in the Byzantine fault-tolerant algorithm is a BFT consensus protocol that is easy to understand and most operations are asynchronous. It is optimized for the PBFT algorithm and only requires two rounds of voting to reach a consensus. Figure 2 is the implementation of this application

The example provides a schematic diagram of a tendermint consensus algorithm.

[0051] The participants in the agreement are called "validators". They take turns to propose transaction blocks and vote on these blocks. Blocks will be submitted to the chain, and each block occupies a "height". The submission block may fail. If it fails, the protocol will start the next round of submission, and a new validator will continue to submit the block at that height. To successfully submit a block, two stages of voting are required: "prevote" and "precommit". In the same round of submission, only if more than 2/3 of the validators have pre-committed the same block, the block can be submitted to the chain.

[0052] As shown in Figure 1, what the verifier does is like dancing a boka dance. More than 2/3 of validators have pre-voted on the same block, which is called a "polka". Each pre-submission must be proven by a Polkadot in the same round. For some reasons, the validator may fail when submitting a block: the current proposer may be offline, or the network may be very slow. The Tendermint consensus algorithm allows them to verify that a validator should be skipped. Before proceeding to the next round of voting, the validator will wait a short time to receive a complete proposal block from the proposer. This dependence on timeout makes the Tendermint consensus algorithm a weakly synchronous protocol rather than an asynchronous protocol. However, the rest of the protocol is asynchronous. Only when more than 2/3 of the validator set is received, the validator will take the next step. One reason the Tendermint consensus algorithm can be simplified is that it uses the same mechanism to submit a block and skip directly to the next round.

[0053] Based on the premise that less than 1/3 of the validators are Byzantine nodes, the Tendermint consensus algorithm guarantees that its security will never be violated. In other words, validators will never submit conflicting blocks at the same height. To achieve this, it introduces some "locking" rules, which modularize the paths in the flowchart. Once a validator pre-commits a block, it is "locked" on that block. Then, it must pre-vote for the locked block, and only in subsequent rounds, with a Polkadot of that block, can it unlock and pre-commit for a new block.

[0054] The consensus on the block with height h may require multiple rounds, and each round includes 3 steps: Propose, Prevote, and Precommit. When a consensus is reached in a certain round (+2/3 of the Precommit vote is received), it will enter the next high consensus, starting from round 0. Let's briefly introduce the tendermint consensus algorithm in conjunction with Figure 2.

[0055] PoLC (Proof of Lock Change) is a very important concept in the Tendermint consensus algorithm, which means that at a certain height and the number of rounds (height, round), a certain block or an empty block (nil) exceeds Summarize the 2/3 Prevote voting set. Simply put, PoLC is the Prevote voting set.

[0056] Propose step: Nodes propose Proposal in turn. When it is a nodes turn to propose, the node will propose Proposal. When the non-proposer node (Proposer) receives the Proposal, it will enter the Pre vote step. If there is Lock- Block, you also need to collect all Prevote votes for Lock-Block.

[0057] Prevote step: After the node enters the Prevote step, if it has a Lock-Block and a new PoLC for another block, and it satisfies LastLockRound<PoLC-Round<Current Round, unlock the LockBlock. At this point, if you still have a Lock-Block, you will vote for the Lock-Block Pre vote, otherwise, you will vote for Proposal or nil. Enter the Precommit step when it times out or when a +2/3 vote for a certain block or nil is received.

[0058] Precommit step: if there is currently a PoLC for a block, lock this block, set LastLockRound to the current Round, and cast Precommit on this block; if there is a PoLC for nil, unlock and

And vote Precommit to nil; otherwise, keep the Lock-Block unchanged and vote nil. When the node receives more than 2/3 of the Precommit vote for a certain block, it can commit this block and enter the next one Highly block consensus.

[0059] In the consensus algorithms of Figure 1 and Figure 2, multiple rounds of voting are used. In the process of multiple rounds of voting, due to network and other reasons, although all consensus nodes have received more than a certain percentage (such as 2/ 3) Pre-submission vote for a proposal, but the pre-submission vote that each consensus node may receive is different. Therefore, consensus is also required for pre-voting over a certain percentage of proposals that are successful in consensus. In the current consensus algorithm, most of the data of all pre-commit results are packaged into a proof of consensus (Proof), and the next round of proposal nodes are submitted together for a new round of consensus. This leads to a waste of bandwidth resources. In order to solve the problems of resource waste and low utilization rate in the multi-round voting process, the embodiment of the present application provides a bandwidth-optimized blockchain consensus method, which solves the problem of bandwidth resource waste in the prior art and effectively optimizes the bandwidth. Resources, improve the utilization rate of bandwidth resources.

Embodiment One

[0061] FIG. 3 is a flowchart of a bandwidth-optimized blockchain consensus method provided by an embodiment of the application, which is applied to a blockchain network including multiple blockchain consensus nodes, and includes the following steps:

[0062] S301. Each consensus node in the blockchain network receives a proposal and performs a pre-voting.

[0063] S302. Each consensus node receives a pre-voting result sent by other consensus nodes in the blockchain network.

[0064] S303. Each consensus node judges the received pre-voting result, and generates a pre-commit result.

[0065] In an embodiment of the present application, in order to optimize bandwidth and improve bandwidth utilization, each consensus node judges the received pre-voting result, when the received pre-voting result is consistent with the blockchain network The ratio of all consensus nodes in is greater than or equal to the predetermined threshold before the pre-commit result is generated. For the value of the predetermined threshold, different consensus algorithms will set different predetermined thresholds. For example, in the BFT algorithm, the predetermined threshold may be 2/3.

[0066] S304. Broadcast the pre-submission result.

[0067] Each consensus node receives the pre-commit result through broadcast.

[0068] S305. Judge the pre-submission result, and package the pre-submission result of the consensus proposal into a consensus proof.

[0069] In an embodiment of the present application, in order to improve the utilization of bandwidth resources, each consensus node judges the pre-submission result, when the pre-submission result is consistent with all consensus in the blockchain network The ratio of nodes is greater than or equal to the first threshold before the pre-commit results of the consensus proposal are packaged into a consensus proof (proof). Similar to the predetermined threshold, the value of the first threshold will be set to different values due to different consensus algorithms. Optionally, the first threshold may also be 2/3.

[0070] It should be noted that the values of the first threshold and the predetermined threshold in the embodiments of the present application will be set to different values due to different consensus algorithms, and are not limited to those listed in the embodiments of the present application. Numerical value.

[0071] S306, the next-high proposal node submits a proposal and the consensus proof; and performs the next round of consensus on the proposal and the consensus proof.

[0072] Because the pre-voting of proposals that reach or exceed a certain proportion of the consensus success also requires consensus, in this step, the pre-commit results are packaged into a consensus proof, and the next high-level proposal node in the next round is combined with It is proposed to submit a new round of consensus together to generate a consensus result.

[0073] In the consensus method of the prior art, all data of the pre-commit results are packaged to generate a consensus proof. and

In the method provided in this application, each consensus node judges its pre-submission result, and only package the pre-submission result of the consensus proposal to generate a consensus proof for a new round of consensus. Taking the BFT algorithm as an example, for the successful consensus of a proposal, a consensus can be reached only after reaching or exceeding 2/3 (predetermined threshold) of pre-voting and reaching or exceeding 2/3 (first threshold) of pre-commitment. Consensus proof It only contains the pre-commit of the proposal that the consensus is successful, and the consensus proof generated by packaging all the pre-commit voting data can improve the bandwidth utilization by 33.3%.

[0074] The method provided in the embodiments of the present application optimizes bandwidth resources, avoids waste of bandwidth resources, and improves bandwidth utilization.

Embodiment Two

[0076] The electronic device of this embodiment will be described in detail below with reference to FIG. 4. Please refer to FIG. 4, at the hardware level, the electronic device includes a processor, and optionally an internal bus, a network interface, and a memory. The memory may include memory, such as high-speed random access memory (Random-Access Memory, RAM), or may also include non-volatile memory (Non-Volatile Memory), such as at least one disk storage. Of course, the electronic device may also include hardware required by other services.

[0077] The processor, the network interface, and the memory can be connected to each other through an internal bus, which can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or Extended Industry Standard Architecture (Extended Industry Standard Architecture, EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of presentation, only one bidirectional arrow is used to indicate in FIG. 4, but it does not mean that there is only one bus or one type of bus.

[0078] The memory is used to store programs. Specifically, the program may include program code, and the program code includes computer operation instructions. The memory may include memory and non-volatile memory, and provide instructions and data to the processor.

[0079] The processor reads the corresponding computer program from the non-volatile memory to the memory and then runs it to form a content recommendation device on a logical level. The processor executes the program stored in the memory, and is specifically used to execute the method operation performed when the server is the execution subject described above.

[0080] The above-mentioned method disclosed in the embodiment shown in FIG. 3 of this embodiment may be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or instructions in the form of software. The above-mentioned processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (Network Processor, NP), etc.; it may also be a digital signal processor (Digital Signal Processor, NP), etc. DSP), Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps, and logical block diagrams disclosed in this embodiment can be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like. The steps of the method disclosed in this embodiment can be directly embodied as being executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0081] The electronic device can also execute the method of FIG. 3, and the blockchain consensus device for bandwidth optimization is implemented as shown in FIG. 3.

The function of the embodiment, this embodiment will not be repeated here.

[0082] Of course, in addition to software implementation, the electronic device of this embodiment does not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to Each logic unit can also be a hardware or logic device.

[0083] Embodiment Three

[0084] This embodiment also provides a computer-readable storage medium that stores one or more programs, and when the one or more programs are executed by an electronic device that includes multiple application programs, The electronic device is caused to execute the method described in the first embodiment. I won't repeat them here.

[0085] Wherein, the computer-readable storage medium, such as a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, etc.

Embodiment Four

[0087] Referring to FIG. 5, it is a schematic structural diagram of a bandwidth-optimized blockchain consensus device provided by this embodiment. The device mainly includes a transceiver module 501 and a processing module 502.

[0088] Wherein, the transceiver module 501 is used for each consensus node in the blockchain network to receive proposals and receive pre-voting results sent by other consensus nodes in the blockchain network.

[0089] The processing module 502 is used for each consensus node in the blockchain network to pre-vote according to the proposal, and to judge the pre-voting result received by the transceiver module, according to the information received by the transceiver module Pre-voting results generate pre-submission results.

[0090] In an embodiment of the present application, in order to optimize bandwidth and improve bandwidth utilization, when the ratio of the pre-voting result received by the transceiver module to all consensus nodes in the blockchain network is greater than or equal to a predetermined threshold Before proceeding to the next step. For the value of the predetermined threshold, different consensus algorithms will set different predetermined thresholds. For example, in the BFT algorithm, the predetermined threshold may be 2/3.

[0091] The transceiver module 501 is also used to broadcast the pre-commit result.

[0092] The processing module 502 is also used for each consensus node to judge the pre-commit result, and package the pre-commit result of the consensus proposal into a consensus proof; the next high-level proposal node submits the proposal and the Consensus proof; the proposal and the consensus proof are carried out to the next round of consensus.

[0093] In one embodiment of the present application, in order to improve the utilization of bandwidth resources, when the ratio of the pre-commit result to all the consensus nodes in the blockchain network is greater than or equal to the first threshold, a consensus will be reached The proposed pre-commit results are packaged into a consensus proof. Similar to the predetermined threshold, the value of the first threshold will be set to different values due to different consensus algorithms. Optionally, the first threshold may also be 2/3.

[0094] It should be noted that the values of the predetermined threshold and the first threshold in the embodiments of the present application will be set to different values due to different consensus algorithms, and are not limited to those listed in the embodiments of the present application. Numerical value

[0095] Specifically, because the pre-voting of proposals that reach or exceed a certain proportion of the consensus success also requires consensus, in this step, the processing module packages the pre-commit results to generate a consensus proof, and the next round of proposal nodes Submit the proposal together with the proposal for a new round of consensus to generate a consensus result.

[0096] In the consensus method of the prior art, all data of the pre-commit results are packaged to generate a consensus proof. In the implementation of this application, the processing module judges the pre-submission result, and only packages the pre-submission result of the consensus proposal to generate a consensus proof for a new round of consensus. Taking the BFT algorithm as an example, the successful consensus of a proposal must reach or exceed 2/3 (predetermined threshold) of the pre-voting and reach or exceed 2/3 (the first threshold) of the pre-submission.

Consensus is achieved. The consensus proof only includes the pre-commitment of the proposal that the consensus is successful, and the consensus proof generated by packaging all the pre-commit voting data can increase the bandwidth utilization by 33.3%.

[0097] The device provided in the embodiment of the present application optimizes bandwidth resources, avoids waste of bandwidth resources, and improves bandwidth utilization.

[0098] In short, the above description is only a preferred embodiment of this embodiment, and is not intended to limit the protection scope of this embodiment. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this embodiment should be included in the protection scope of this embodiment.

[0099] The systems, devices, modules, or units illustrated in the foregoing embodiments may be specifically implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.

[0100] Computer-readable media including permanent and non-permanent, removable and non-removable media can be implemented by any method or technology for information storage. The information can be computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0101] It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements not only includes those elements, It also includes other elements that are not explicitly listed, or elements inherent to the process, method, commodity, 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, commodity, or equipment that includes the element.

[0102] The various embodiments in this embodiment are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. . In particular, as for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment.

CN 110012100 Β