CN112017051B

CN112017051B - Block chain system, related method, user node and storage medium

Info

Publication number: CN112017051B
Application number: CN202011176219.9A
Authority: CN
Inventors: 饶上荣
Original assignee: Beijing Yizhen Xuesi Education Technology Co Ltd
Current assignee: Beijing Yizhen Xuesi Education Technology Co Ltd
Priority date: 2020-10-29
Filing date: 2020-10-29
Publication date: 2021-02-12
Anticipated expiration: 2040-10-29
Also published as: CN112017051A

Abstract

The application provides a blockchain system, a related method, a user node and a storage medium, wherein the blockchain system comprises: a plurality of user nodes in communication with each other; at least part of the user nodes are used as working nodes, and the types of the working nodes comprise: a transaction processing node and a block output node; the transaction processing node is used for processing or verifying transactions; when the first transaction processing node is used as a trader to process a transaction to form a transaction processing result, a predetermined number of second transaction processing nodes are used as verifiers to verify the transaction processing result; the block output node is used for generating a block according to the corresponding transaction of the verified transaction processing result when the block output node is used as a block output member; the work node type may also have review nodes that constitute a review board to review errors and penalties. In the system, the computing power of each user node is fully utilized to undertake the mutual cooperation of the responsibilities of transaction processing, verification, review and the like, so that the transaction processing speed of the block chain is greatly improved.

Description

Block chain system, related method, user node and storage medium

Technical Field

Embodiments of the present invention relate to the field of distributed network technologies, and in particular, to a blockchain system, a related method, a user node, and a storage medium.

Background

The blockchain is in a distributed system, achieves distributed consistency through unified accounting, global unique sequencing and confirmation, and has operation traceability and non-repudiation. These characteristics have an unparalleled role in building trusted computing, digital transactions. However, the speed of transaction processing for blockchains has been a fundamental significant problem. If the transaction processing speed is difficult to increase, it is difficult to effectively use the transaction in business.

With the development of block chain related technology, there has been a scaling up in speed. For example, the earliest bitcoin networks used a Proof of Work (POW) consensus that their transaction rate could only be processed a few transactions per second; and then to a subsequent commercial distributed operating System (Eos), that is, a block chain operating System designed for commercial distributed applications. EOS is a new blockchain architecture introduced, aiming at realizing the performance extension of distributed application. The problem of delay and data throughput is solved by an EOS (evolved Proof of station, DPOS) mode through parallel chains, the EOS can reach thousands of transaction processing strokes per second, about 7 bits of coins per second and 30-40 strokes per second, and therefore the EOS achieves the purpose of improving the huge block chain transaction processing speed.

However, these technologies do not fully utilize the computing power of users of the blockchain network, so that the overall transaction speed of the system is difficult to be increased on a large scale.

Disclosure of Invention

In view of the above, embodiments of the present application provide a block chain system, a related method, a user node and a storage medium, which solve the technical problems in the prior art.

An embodiment of the present application provides a block chain system, including:

a plurality of user nodes in communication with each other; at least part of the user nodes are used as working nodes, and the types of the working nodes comprise: a transaction processing node and a block output node;

the transaction processing node is used for processing or verifying transactions; when the first transaction processing node is used as a trader to process a transaction to form a transaction processing result, a predetermined number of second transaction processing nodes are used as verifiers to verify the transaction processing result;

and the block output node is used for generating a block according to the corresponding transaction of the verified transaction processing result when the block output node is used as a block output member.

Optionally, the traders are matched among the trading processing nodes according to trader qualification conditions including at least one of: transaction credibility; transaction processing capabilities; and recording the inferior tracks.

Optionally, the judgment basis of the transaction reputation degree includes at least one of the following: a record of successful transactions, owned vouch-for digital assets; the judgment basis of the transaction processing capacity comprises the following steps: transaction processing speed.

Optionally, each transaction processing node is located on a consistent hash path.

Optionally, the trader is the first trading processing node on the consistent hash path that qualifies as a trader.

Optionally, each of the validators is a predetermined number of transaction processing nodes arranged behind a trader on the consistent hash path.

Optionally, when there are multiple transactions to be processed, each trader processes the multiple transactions in a multi-thread manner.

Optionally, the trader processes the trade to form a trade processing result, including:

the trader processes the transaction to obtain a read operation set and a write operation set of the account related to the transaction, and signs to form a transaction processing result which is stored in an intermediate result set;

the verifier verifies the transaction processing result, including:

transaction processing results are obtained from the intermediate result set and verified.

Optionally, the types of the working nodes further include: evaluating nodes; a plurality of the review nodes form a review board for reviewing the transactions and/or issues presented to the block.

Optionally, each review node is selected from each working node through a delegation interest certification consensus mechanism.

Optionally, the review board obtains the review result through a Byzantine fault-tolerant consensus mechanism.

Optionally, the processing mode of the problematic transaction and/or block includes at least one of the following:

when the verifier of the transaction verifies that the transaction has problems, the verifier submits the transaction to a review board;

submitting the verification blocks to a review committee when the verification blocks have problems by each candidate;

the user node submits the transaction with the problem in the generated block to the selected transaction processing node for review.

Optionally, when a block has a problem, if the review board determines that a blockman makes a mistake, punishing the blockman; or if the review board determines that the blocking member does not make mistakes, the transaction processing node is informed to review the transactions in the block, so that the blocking member can re-block the transactions with problems after rejecting the transactions with problems, and the review board punishs the wrong transaction member.

Optionally, the transaction processing node reviews the transaction situation, including at least one of the following:

when receiving a notification for rechecking the transaction in the block with the problem, matching the transaction which needs to be responsible for each transaction processing node in the block with the problem for rechecking;

when a review request of a user node related to the transaction for the transaction is received, the requested transaction processing node is used as an endorsement node to endorse the transaction, and the transaction processing node which needs to be responsible for the endorsed transaction is reviewed.

Optionally, the endorsement node endorses a transaction, including: modifying a location of the transaction in the consistent hash path such that a transaction processing node reviewing the transaction is distinct from a trader processing the transaction.

Alternatively, the issues that arise with the transaction are submitted to the review board by the verifier of the transaction.

Alternatively, the problem with the block is verified by each candidate other than the blockmaker and submitted to the review board.

Optionally, locking the corresponding reading operation of the working node through a distributed reading lock for the account needing to be read in the transaction processing or verification; and locking the corresponding write operation of the working node through a distributed write lock on the account needing to be written in the transaction processing or verification.

Optionally, the block output member is alternatively acted by a plurality of block output nodes.

Optionally, each block node is selected from each working node through a delegation interest certification consensus mechanism.

The embodiment of the application provides a block chain management method, which is applied to a block chain system comprising a plurality of nodes which are communicated with each other; the method comprises the following steps:

when a first transaction processing node of the blockchain system is used as a trader to process corresponding transactions of the transaction requests to form transaction processing results, a predetermined number of second transaction processing nodes are used as verifiers to verify the transaction processing results;

when the block output section of the block chain system is used as a block output member, a block is generated according to the corresponding transaction of the verified transaction processing result.

Optionally, the block chain management method includes: when a problem occurs in transaction verification, a review board consisting of review nodes in the blockchain system reviews the problem-occurring transaction.

Optionally, the block chain management method includes: when a block verification is in problem, a review board consisting of review nodes in the block chain system conducts corresponding review.

The embodiment of the application provides a transaction processing method, which is applied to the block chain system; the transaction processing method comprises the following steps:

a first transaction processing node in the blockchain system confirms the identity of a trader per se according to transaction matching and processes the transaction;

the second transaction processing nodes of the preset number confirm the identities of the self authenticators and verify the transaction processing results.

The embodiment of the application provides a block output method, which is applied to a block output node in a block chain system; the block output method comprises the following steps:

when the node is used as a block output member, the block output node acquires a transaction, and the transaction processing result of the transaction is verified; the verification is performed by a transaction processing node acting as an authenticator;

and generating a block according to the transaction passing the verified transaction processing result.

The embodiment of the application provides a review method, which is applied to the block chain system; the evaluation method comprises the following steps:

the review board formed by each review node in the block chain system reviews the transaction and/or the problems occurring in the blocks;

penalizing the working node causing the problem.

The embodiment of the application provides a user node, which comprises a communicator, a memory and a processor, wherein the communicator is used for communicating with an external network; the memory has stored thereon a computer program executable by the processor, the processor implementing the computer program as a worker node in the blockchain system.

The embodiment of the application provides a computer readable storage medium, on which a computer program is stored, and the computer program is executed to implement the working node in the blockchain system.

Compared with the prior art, the technical scheme of the embodiment of the application has the following beneficial effects:

each user node selects working nodes which play different roles, such as transaction processing, review and the like, through a common identification mechanism, and through the cooperation among the nodes, the corresponding flow and the decomposition operation are used, the calculation resources and the capability of each user node in the blockchain system can be fully utilized to complete the transaction processing and the block output, so that the speed of processing the transaction of the blockchain can be approximately horizontally expanded, and the bottleneck of the processing capability of the blockchain transaction is solved.

Drawings

Fig. 1 is a schematic diagram of a block and a block chain.

Fig. 2 is a schematic diagram of a hardware structure of a blockchain system.

Fig. 3 is a schematic diagram of a logic structure of a block chain system according to an embodiment of the present application.

Fig. 4 is a schematic diagram illustrating the principle of managing transaction processing nodes and transactions through a consistent hash path in the embodiment of the present application.

Fig. 5 shows a flow diagram of a consensus mechanism based on the PBFT algorithm.

Fig. 6 is a flowchart illustrating a block chain management method according to an embodiment of the present application.

Fig. 7 is a flow chart illustrating a transaction processing method according to an embodiment of the present application.

Fig. 8 is a flowchart illustrating a block output method according to an embodiment of the present application.

Fig. 9 is a schematic flow chart of a review method in the embodiment of the present application.

Fig. 10 is a schematic structural diagram of a user node in the embodiment of the present application.

Detailed Description

The block chain is a distributed shared account book and a database, and has the characteristics of decentralization, no tampering, trace retaining in the whole process, traceability, collective maintenance, openness and transparency and the like. The characteristics ensure the honesty and the transparency of the block chain and lay a foundation for creating trust for the block chain. Known block chain types are Public block chain (Public block chain), Private block chain (Private block chain) and alliance block chain (Consortium block chain).

The public chain is a block chain which can be accessed into the system by anyone at any time to read data, send confirmable transactions and compete for billing. Public chains are generally considered to be completely decentralized because no one or entity can control or tamper with the reading and writing of data therein. Bitcoin and ether house are typical public chains. Common public chains include Etherum (Ethereum), grapefruit (Citrus junos), TT (Thundercore) chain, QTUM quantum chain, etc.

A private chain refers to a blockchain that is open to an individual person or entity (e.g., a business). Such as a blockchain in which an enterprise participates as an inner member.

The public degree of the account book of the alliance chain is between the public chain and the private chain. The alliance chain refers to a blockchain which is managed and maintained by a plurality of organizations together, and nodes participating in the blockchain are selected in advance. The alliance chain only opens all or part of functions for alliance internal members, and reading, writing and accounting rules of information on the chain are set according to alliance consensus. For example, in practical applications, the plurality of organizations are, for example, a plurality of enterprises in a certain industry, such as banks, and the like, and thus the federation chain is also referred to as "industry chain" in this scenario. The privacy design permissions between the private chain and the federation chain may differ, and the permissions design requirements in the federation chain are often more complex.

As shown in fig. 1, the blockchain is a chain of connected blocks, and each block records a hash value of the transaction information that is confirmed by common identification. The validated trusted transaction record is time stamped (Timestamp) and stored on a block of the block chain. Each block comprises a Hash value (Hash) of a previous block, wherein the block N-1 is a block previous to the block N, and the block N is a block previous to the block N +1, and the blocks are linked into a block chain; inside each block, all transaction records are stored in a structure such as a merkel Tree (Hash Tree), which is simply represented as a Hash Tree (Hash Tree).

As mentioned above, the blockchain is a distributed shared book and database, and each node in the blockchain system performs blocking and updating under a consensus mechanism.

As shown in fig. 2, a hardware architecture of a blockchain system 200 in an embodiment is shown, which includes a plurality of user nodes 201. Each user node 201 may be implemented by a server, a server group, a tablet Computer, a smart phone, a Personal Computer (PC), a notebook Computer, or other devices in which a blockchain software program is installed, or implemented by a distributed processing system having a plurality of configurations among these devices. The user nodes 201 are connected through point-to-point network communication to transmit and receive information to and from each other. The peer-to-peer (P2P) network is an internet system that does not have a central server and relies on user groups (peers) to exchange information, and it is used to reduce nodes in the past network transmission to reduce the risk of data loss. Unlike a central network system with a central server, each client of a peer-to-peer network is a node and can also assume the functions of a server.

It should be noted that, although the user node 201 shown in the above example is presented as a physical device such as a server, a smart phone, a PC, etc., in fact, these physical devices are only carriers, and it mainly implements the functions of the user node 201 by installing and running the blockchain software program, for example, implements a mechanism for common recognition among the user nodes 201, and thus there is no need to limit the types of the physical devices. In determining the scope of the present application, a "node" is a physical device that is substantially controlled by a blockchain software program installed to perform a desired function, including but not limited to, for example, bitcoin exchange software programs, firecoins, polices, etc., wallet-like imtokens, etc.

In view of the problems that in the prior art, the block chain system has insufficient parallel processing capability and fails to fully exert the capability of each user node, so that the transaction efficiency is still low, the application provides a corresponding solution.

Fig. 3 is a schematic diagram of a logic structure of the blockchain system in the embodiment of the present application.

In the blockchain system including a plurality of user nodes communicating with each other, at least some of the user nodes are working nodes, and the rest may be ordinary user nodes 301. In some examples, the types of the worker nodes include: transaction processing node 302, and egress block node 303.

The transaction processing node 302 is used to process or verify transactions. In some examples, to illustrate transaction processing, assuming a transaction is a transfer of an asset C (e.g., bitcoin, universal currency, etc.) from user a to user B, processing the transaction may entail determining that a read/write operation is to be performed on user a's account, user B's account, which may include: reading the balance of the account of the user A and the account of the user B, and judging whether the balance of the account of the user A is enough to transfer the asset C; if so, modifying the balance of the account of the user A by C, and modifying the balance of the account of the user B by C. For example, the read/write operations for each transaction may be placed into a set of read operations and a set of write operations, respectively.

In particular implementations, each of the transaction processing nodes 302 may have an identity of a trader responsible for processing pending transactions. The pending transaction may be a transaction request from the general user node 301 or may also be a transaction request from the working node. The generic user node 301 may not have the capability of transaction processing, verification.

In some examples, the traders are matched among the trading processing nodes 302 according to trading membership conditions that include at least one of: transaction credibility; transaction processing capabilities; and recording the inferior tracks.

Optionally, the reputation of the transaction may be obtained through historical data of the transaction processing node 302, including, for example, records of success, error, or failure of previous transaction processing of the transaction processing node 302 or statistical information thereof, or may be embodied by how much assets are owned, for example, a certain proof of interest (token) is owned.

Optionally, the transaction processing capability may be determined by at least one of transaction processing speed, hardware/software/network configuration performance, or computing resources of the transaction processing node 302.

Optionally, the inferior track record refers to that there is an error in the operation in the transaction processing, for example, the amount of the operation transfer is inconsistent with the transaction request; the fewer the number of occurrences of the bad track record, the higher the reliability of the transaction processing node 302. The transaction processing node 302 is most reliable when there is no defect record, so the transaction processing node 302 without defect record can be set under the most strict condition to be used as a trader.

One of the transaction credibility, the transaction processing capacity and the inferior trace record can be selected as a transaction membership condition, and any combination of a plurality of kinds can be selected to form the transaction qualification condition. In some optional examples, when multiple of the transaction credibility, transaction processing capability and poor track record are combined, each condition may be satisfied, for example, the transaction credibility requires that the token value N be possessed or more, and the transaction processing speed is on average M pens/S and no poor track record. Or, in other examples, the result may be a result of combining multiple conditions according to weights, for example, a transaction processing node 302 is scored on the transaction reputation, the transaction processing capability, and the bad track record, and configured with weights respectively to be fused to obtain a final score, and if the score is higher than a preset threshold, the transaction processing node is considered to have the trader qualification; otherwise, the trader qualification is not met.

In order to accelerate the processing speed of each trader, optionally, each trader processes multiple trades in a multi-thread manner when the multiple trades need to be processed.

In some examples, in each of the transaction processing nodes 302 (each of which is within the dashed circle a in fig. 3), in the case where the transaction processing result is formed by processing the transaction with the first transaction processing node J in fig. 3 as a trader, a predetermined number of second transaction processing nodes Y1, Y2 are also required as validators to validate the transaction processing result of the first transaction node; for example, the number of second transaction processing nodes may be 2 or more.

In some examples, the process of transaction processing and verification is specified. Illustratively, a trader processes a transaction to be processed to obtain a read operation set and a write operation set of an account involved in the transaction, and signs to form a transaction processing result which is stored in an intermediate result set; the verifier obtains and verifies transaction processing results from the intermediate result set.

The intermediate result set may be a distributed database implementation, such as a distributed database based on an InterPlanetary File System (IPFS) network transport protocol, that is capable of persistently and distributively storing and sharing files.

In some examples, optionally, the trader is the first trading processing node 302 on the consistent hash path that qualifies for a trader. Optionally, each of the validators is a predetermined number of transaction processing nodes 302 arranged behind the trader on the consistent hash path.

It should be noted that consistent hashing is one of optimization methods of a Distributed Hash Table (DHT).

As shown in fig. 4, the consistent hash algorithm is to map the whole hash value space into a virtual circular ring, which is called a hash ring 400, taking SHA256 algorithm as the hash function as an example, the hash function mapped onto the hash ring 400 has a value range of (0, 2256), i.e. the hash space is 2256, in the example of fig. 4, the transaction processing nodes 401 mapped onto the hash ring 400 are represented by circles, and the transactions 402 mapped onto the hash ring 400 are represented by squares, although in fig. 3, the numbers of the transaction processing nodes are 401, and the numbers of the transactions are 402, they are only represented as individuals of the same type in a global perspective, but not as they are the same individual, and there may be a difference between them in a microscopic perspective, such as in a hard/software configuration.

Each transaction processing node 401 has its node ID, and a transaction ID is generated for each transaction 402 in the blockchain; inputting the node ID into the hash function to obtain a hash value mapped to the hash ring 400 by the transaction processing node 401; similarly, the transaction ID is input into the hash function to obtain the hash value of the transaction 402 mapped to the hash ring 400, and then a hash routing table is formed to record the mapping relationship of the transaction processing node 401 and the transaction 402 to be processed mapped to the hash ring 400.

By mapping to hash ring 400, transaction processing nodes 401 are arranged along the hash ring, and transactions are distributed among transaction processing nodes 401; wherein, according to the clockwise direction of the hash ring being a consistent hash path, as shown by an arrow T in fig. 3, each transaction processing node 401 processes each transaction with the previous transaction processing node 401, for example, the transaction processing node N-1 and the transaction processing node N are distributed adjacent to each other along the clockwise direction, and there are transactions M, M +1 and M +2 between the two, so that the transaction processing node N is responsible for processing the transactions M, M +1 and M + 2. In a specific implementation, the node ID may be an address (e.g., a hash value) in the blockchain system correspondingly allocated to each user, or may also be an IP address (e.g., a public network address) or a MAC address, etc. capable of representing a unique identity of the node; in addition, the transaction ID may be generated according to the calculation method of different blockchain systems, which is not described in detail herein.

In a specific example, when, for example, a common user node sends a transaction request, a transactor matching for a to-be-processed transaction corresponding to the transaction request is performed on the consistent hash path according to the transaction membership condition, there may be a plurality of transaction processing nodes 401 meeting the transaction membership condition, and the first one of the transaction processing nodes may be a transactor.

Accordingly, for each first transaction processing node on the consistent hash path as a trader, a predetermined number of second transaction processing nodes are followed as validators to validate the transaction processing results. For example, in the case where the transaction processing node B is determined to be the trader of the transaction a to be processed, the two adjacent transaction processing nodes C and D following B on the consistent hash path may be determined to be the validators responsible for validating the transaction processing result of the transaction a.

In a specific example, each transaction, when processed by a trader, will have a current transaction execution environment, including the transaction itself and the data it relates to; the verification, i.e. checking according to the transaction execution environment at the time of transaction, includes checking that the data involved in the transaction processing needs to be correct; if the verification result is different from the transaction processing result, it is considered that the malicious situation is possible. If the processing possibly with malicious intentions is found, the transaction processing result is considered to have a problem and is disabled; alternatively, a review board formed of review nodes may be submitted for review of the problematic transaction processing results, as will be described in detail in embodiments below.

As further shown in fig. 3, the block output node 303 is configured to generate a block according to a corresponding transaction of a verified transaction processing result when the block output node is used as a block output member. The generated tiles may then be broadcast to various user nodes for consensus.

In the specific implementation, since the transaction is verified during processing, the blocking member only needs to confirm and adjust each transaction sequence according to the transaction dependency relationship (the transaction dependent in the read operation set and the write operation set formed by processing the processing results of each transaction), form the final result and generate the block according to the final result. After the block is generated, a notification is broadcast to the network.

In some examples, multiple out-of-block nodes 303 may be elected in the blockchain system through a consensus mechanism, as shown by the dashed circle B in the figure; the consensus mechanism is for example a trust rights accreditation (DPOS) consensus mechanism, which principle is to let each person holding crypto-currency vote, thus generating n super nodes, i.e. in this embodiment egress block nodes. In other examples, this may also be accomplished through a Proof Of rights (PoS) mechanism. However, the consensus algorithm is a more efficient and democratic version than the Delegated Proof Of rights Of rest (DPOS).

Optionally, the multiple block output nodes 303 act as block output members in turn, and the other block output members are used as candidate block output members.

For example, 7 out-of-block nodes 303 are elected by a delegation rights and interests (DPOS) mechanism, ordered by the transmission delay characteristics between the out-of-block nodes, and the out-of-block is rotated by the 7 out-of-block nodes. Each time, one block output node is responsible for outputting blocks, the block output person outputs one block every 1 second, continues to output 10 blocks, and then delivers to the next block output person for outputting blocks.

In the example of fig. 3, in the blockchain system, the types of the working nodes may further include: review node 304. A plurality of the review nodes 304 form a review board 305 for reviewing the issues with transactions and/or blocks. It should be noted that the review node 304 and the transaction processing node 302 may be the same user node, or may be different user nodes, that is, one user node may have multiple identities.

In a specific implementation, the review node 304 may also be selected from the work nodes through a delegation rights and interests (DPOS) consensus mechanism, for example, 36 from the work nodes are selected as the review board 305. Of course, the number of review nodes 304 may vary according to actual needs, and is not limited to this example.

Optionally, the review board 305 obtains the review result through a Byzantine Fault-tolerant consensus mechanism, such as a Byzantine Fault-tolerant (BFT) consensus mechanism, or a Practical Byzantine Fault-tolerant (PBFT) consensus mechanism.

In particular implementations, the federation chain system may employ a consensus mechanism based on the Byzantine Fault Tolerant (BFT) protocol to a greater extent. Byzantine Fault Tolerance (BFT) originates from the problem of the Byzantine general and is a system feature that can resist a series of losses caused by the problem of the Byzantine general. This means that even if some nodes fail or have poor trace behavior, the blockchain system can tolerate these errors and continue to operate as long as predetermined conditions are met, for example, the number of byzantine nodes (e.g., the number of failed or poor trace nodes) must be less than 1/3 of the total number of nodes in the network system.

In a block chain system adopting a BFT consensus mechanism, a node (called a leader node for short) with a leader identity in a plurality of nodes is responsible for generating and proposing a block, and other nodes (called slave nodes for short) with slave identities not with the leader identity vote for the block. Through multiple rounds of communication, the block is finally confirmed. This process is repeated to generate new blocks each having an appended number. Each time a block is generated, the leader node broadcasts the block to other non-leader nodes. The non-leader node votes for the block and returns the voting result to the leader node. To be able to handle byzantine failures as well as crashes or packet loss failures, such a process would iterate several times to finally identify the block. Different BFT protocols will have different iterations, but the approximate procedure is similar. And finally, sorting the blocks according to the increasing direction of the sequence numbers to form a block chain.

In some examples, a common recognition mechanism based on a Practical Byzantine Fault-tolerant algorithm (PBFT) solves the problem that the original Byzantine Fault-tolerant algorithm is not efficient, and reduces the algorithm complexity from the exponential level of the number of nodes to the square level of the number of nodes, so that the Byzantine Fault-tolerant algorithm becomes feasible in Practical system application.

The design of the PBFT algorithm is intended to let most honest nodes in the system cover the behavior of rogue nodes or invalid nodes. The number of nodes of the PBFT algorithm is fixed, the node identity is determined in advance, dynamic addition or deletion cannot be achieved, and the method is suitable for a federation chain or private chain scene with a fixed number of nodes.

As shown in fig. 5, a flow diagram of a consensus mechanism based on the PBFT algorithm is shown. Wherein C represents a client, and 0, 1, 2 and 3 represent 4 nodes respectively; in this view (view), 0 is the leader node, 1, 2, 3 are the slave nodes; assume 3 is a failed node. The flow of the whole consensus mechanism is described in conjunction with the above figure:

request (Request) phase: client C sends a request to leader node 0;

preliminary (Pre-preparation) stage: the node 0 broadcasts the request of C and spreads the request to the

subordinate nodes

1, 2 and 3;

preparation (Prepare) phase: after receiving the information, the

nodes

1, 2 and 3 record and broadcast again, the node 1 sends the information to the

nodes

0, 2 and 3, and the node 2 sends the information to the nodes 0, 1 and 3, and the information cannot be broadcast due to faults.

Confirmation (Commit) phase: in the Prepare stage, if the

nodes

0, 1, 2 and 3 receive the same requests with more than a certain number (2F, in actual use, F is the tolerable number of Byzantine nodes), entering the Commit stage and broadcasting the Commit request;

a Reply (Reply) phase: in the Commit stage, if one of the

nodes

0, 1, 2 and 3 receives more than a certain number (2F +1) of the same requests, feeding back the request to the node C;

according to the above process, the consistency can be normally operated under the condition that N is more than or equal to 3F +1, N is the total node number, and F is the total number of the Byzantine nodes, namely 1/3 that the number of the Byzantine nodes can not exceed the total number.

Again, taking the above principle as an example, a PBFT is more intuitively explained. Let N =4 and F =1, i.e. there are four nodes, one of which is a byzantine node, i.e. the above-mentioned node 3 is still assumed to be a failed node.

Client C sends a request to node 0, assuming the request content is "1" here; after receiving the request of C, the node 0 broadcasts the request and diffuses the content '1' of the request to the

nodes

1, 2 and 3; after receiving the content '1', the

nodes

1, 2 and 3 broadcast again, wherein the node 1 sends the content '1' to the

nodes

0, 2 and 3, the node 2 sends the content '1' to the nodes 0, 1 and 3, and the node 3 cannot broadcast due to faults; nodes 0, 1 and 2 respectively receive three request contents "1" in the last stage, and the number of the three request contents exceeds 2, so that the nodes 0, 1 and 2 respectively broadcast the request contents "1"; at this time, if one node (any one of 0, 1 and 2) receives 3 (i.e. 2 x 1+ 1) commit messages, C is fed back.

In yet another example, considering the scalability problem of the PBFT algorithm, a proxy Byzantine Fault tolerance algorithm (DBFT) is adopted by the latter. The method is the same as a delegation rights and interests certification algorithm (DPOS) consensus mechanism, a rights and interests holder votes to generate a proxy bookkeeper, and the proxy bookkeeper verifies and generates blocks, so that the number of nodes in the consensus process is greatly reduced, and the inherent capacity expansion problem of the BFT algorithm is solved.

In order to improve the efficiency of the blockchain system, the DBFT improves the request response mode of the C/S (client/server) architecture in the PBFT into a peer node mode suitable for the P2P network, and improves the static consensus participant node into a dynamic consensus participant node capable of entering and exiting dynamically, so that the DBFT is suitable for the open node environment of the blockchain.

In the DBFT algorithm, the super node participates in accounting, and common nodes can see the consensus process and synchronize the book information, but do not participate in accounting. The total n super nodes are divided into an agenda and n-1 agendas, and the agenda will be elected in turn. At each billing, the chairman initiates a block proposal (the contents of the block to be billed), and once at least (2n +1)/3 billing nodes (chairman plus the agenda) agree with the proposal, the proposal becomes the block to be finally issued.

In another example, there is a fast Byzantine Fault tolerant Algorithm (FBFT). Since PBFT is already the most practical protocol in the BFT family, if when a certain number of nodes (e.g., hundreds) are reached, there will be a large number of broadcast messages between nodes; and because the node needs signature verification every time it receives a message, it causes huge computation. FBFT is a BFT family protocol that uses aggregate signatures to improve efficiency, and node identity validation using POS optimizes PBFT consensus creating more efficient FBFT consensus.

In the FBFT algorithm, the slave nodes do not broadcast their votes, and only need to send the votes to the leader node in a digital signature mode, and the leader node synthesizes the received digital signatures into a multiple signature of a data quanta O (1) and broadcasts the multiple signature, so that the message complexity of the whole consensus process is reduced from O (n) to O (n).

There may be other variations of the BFT algorithm, which are not described here. These Byzantine fault-tolerant consensus mechanisms, such as primitive BFT, PBFT, DBFT, FBFT, etc., can be applied to the review of the review board 305 in the embodiments of the present application, and are not limited thereto.

In the following, a description is given of the specific review function of the review board 305.

In some examples, when the validator of the transaction verifies that the transaction is out of order, this information is submitted to the review board 305. For example, when verifying the transaction processing result of the transaction member a on the transaction B, the verifier C finds that the transaction processing result is incorrect, and submits the transaction processing result to the review board 305 for review.

When the review board 305 determines that the transaction processing result of the transaction B has an error, if the responsibility lies in the trader a, the trader a can be considered to be malicious, and the trader a can be punished from the aspects of qualification or rights, for example, a bad track record is formed, so that the transaction credibility is reduced; or deducting the trader's deposit, etc.

In some examples, the transactant's ability to not process a transaction late, which may be malicious or low-performing, may be reduced in its eligibility to process a transaction. In particular implementations, if a transaction is not processed late, it may be processed by the next trader in the consistent hash path.

In some scenarios, individual transactions may not be processed in a timely manner or may be tolerated, a timeout (e.g., 3 seconds) may be set for no processing, the transaction may be processed by other traders, etc.

In some examples, each candidate other than the blockmaker verifies that the block is having problems, this information is submitted to the review board 305. If 7 block output nodes exist, the block output member is the block output node 1, and the block output nodes 2-6 can be used as candidate block members; or according to the alternate sequence, the block output node 2 is used as a candidate block member; the candidate blocking member can generate a block by taking a blocking rule completely identical to the blocking rule of the candidate blocking member as a verification rule, and if the two blocks are consistent, the verification is passed; if not, the block generated by the blocking personnel may have problems.

When a block has a problem, it may be an error in the processing of the block output personnel or an error in the transaction in the block.

In some examples, the review board 305 penalizes a blockmaker if the review result is that the blockmaker is in error. For example, the out-block node identity of the out-block node with the error is removed, and then a new out-block node selected from the outside can be filled.

In some examples, if the panelist does not make an error, the review board 305 (or other node) can notify each transaction processing node 302 to review the transactions in the problematic block, upon receiving notification to review the transactions in the problematic block, each transaction processing node matches its required transactions for review in the problematic block; if the review finds that the block contains a problematic transaction, the deblocker can re-deblock the problematic transaction after culling it, and the review board 305 penalizes the problematic transaction-related transaction processing node 302 accordingly.

In particular implementations, each transaction processing node 302 matches the transactions for which it needs to be responsible based on the problem block and the transactions therein, and reviews the transactions.

Optionally, the transaction processing node 302 matches the transaction for which it needs to be responsible, which may be implemented according to the consistent hash path, i.e. hash ring. Specifically, the transaction ID of each transaction included in the block is obtained according to the block, the hash value of the node ID of each transaction processing node 302 corresponding to the transaction is found on the consistent hash path according to the transaction ID, and each found transaction processing node 302 is notified to review the respective responsible transaction.

In some examples, the user node may check the generated block for transactions related to itself, and when an error is found in the transaction result, the transaction result may be submitted to a certain transaction processing node 302 for review and authentication, and this transaction processing node 302 may act as an endorsement node to endorse the transaction for review by the transaction processing node responsible for the endorsed transaction, for example, a review mark is printed on the transaction requiring review and authentication.

Optionally, the position of the transaction in the consistent hash path may be changed by adding the review mark, so that the transaction processing node 302 for reviewing the transaction is different from a trader who processes the transaction, thereby preventing the same trader from reviewing the processed transaction and possibly performing cheating. In a specific implementation, the review mark may be a transaction ID for modifying a transaction with a problem, for example, a "check" character string is added, and may be in any manner, so that a position of a calculation result (preset in the hash ring) of the modified transaction ID on the hash ring changes, and an original trader is not found through a consistent hash path.

If the review has a problem, the block is suspended, the problematic transaction is eliminated, and then the block is removed again, and corresponding punishment can be performed on the transaction-related transaction processing node 302 with the problem, for example, the reporting review board 305 performs punishment on the wrong trader, such as reducing the trader qualification or rights and the like.

In some examples, to ensure data consistency during transaction processing or validation, the blockchain system may also employ distributed read/write locks. The actual function of the distributed read lock is to realize single-path or multi-path read-only locking of data, and write operation is not allowed; the actual function of a distributed write lock is to implement a single write-only, but not readable, path for data.

In a specific implementation, the account to be read involved in the transaction processing or verification thereof is locked by the corresponding reading operation of the working node through a distributed reading lock, for example, only a plurality of transaction processing nodes 302 are allowed to read the account balance, but not to be modified. And locking the corresponding write operation of the working node for the account needing to be written in the transaction processing or verification thereof through a distributed write lock, for example, only allowing a single transaction processing node 302 to modify the account balance, and allowing other working nodes not to read the account balance or modify the account balance at the moment.

Based on the principle described in the above embodiment of the blockchain system, referring to fig. 6, a method for managing blockchain in the embodiment of the present application is shown, and functions of user nodes in the blockchain system are connected in series through a method flow to intuitively explain the application of the blockchain system. Since the technical features of the blockchain system have been described in detail in the previous embodiments, the details are not repeated in this embodiment.

The block chain management method comprises the following steps:

step S601: the first transaction processing node of the blockchain system is used as a trader to process the corresponding transaction of the transaction request to form a transaction processing result;

step S602: a predetermined number of second transaction processing nodes are used as verifiers to verify whether the transaction processing result has problems;

if the transaction is verified, i.e. there is no problem, step S603 is entered: when the block output node of the block chain system is used as a block output member, a block is generated according to the corresponding transaction of the verified transaction processing result.

Alternatively, if the transaction verification is not passed, i.e. there is a problem, step S604 is entered: when a problem occurs in transaction verification, a review board consisting of review nodes in the blockchain system reviews the problem-occurring transaction.

Optionally, after step S604, the method may further include:

step S605: the trader of the transaction that has a problem is punished.

Optionally, after step S603, step S606 may be further included: the candidate blockman verifies whether the block generated by the blockman has a problem; if there is no problem in the block, the process proceeds to step S611, and the block is continuously output.

Step S607: when a problem occurs in the verification of the given block, a review board composed of review nodes in the block chain system performs corresponding review.

Optionally, after the step S607, the branch may be performed according to the responsible person with the problem in the block, which specifically includes:

step S608: if the blocking person makes an error, punishing the blocking person;

step S609: if the error is not caused by the block discharging person, the transaction processing nodes review the transaction in the block with the problem, and the block discharging person continues discharging the block after the transaction with the problem in the block is found by review and the block is removed.

Optionally, the method may further include step S610: and informing a review board to punish the traders corresponding to the problematic trades.

Fig. 7 is a schematic flow chart showing a transaction processing method in the embodiment of the present application.

The transaction processing method may be applied to a transaction processing node in a blockchain system, such as the transaction processing node in the foregoing fig. 3 embodiment or fig. 6 embodiment. Therefore, the technical features of the specific implementation can be referred to the previous embodiments, and are not repeated herein.

The transaction processing method comprises the following steps:

step S701: a first transaction processing node in the blockchain system confirms the identity of a trader per se according to transaction matching and processes the transaction;

step S702: the second transaction processing nodes of the preset number confirm the identities of the self authenticators and verify the transaction processing results.

Fig. 8 is a schematic flow chart illustrating a block output method in the embodiment of the present application.

The method of surrendering blocks may be applied to a block-out node in a blockchain system, such as the transaction processing node in the embodiment of fig. 3 or the embodiment of fig. 6. Therefore, the technical features of the specific implementation can be referred to the previous embodiments, and are not repeated herein.

The block output method comprises the following steps:

step S801: when the node is used as a block output member, the block output node acquires a transaction, and the transaction processing result of the transaction is verified; the verification is performed by a transaction processing node acting as an authenticator;

step S802: and generating a block according to the transaction passing the verified transaction processing result.

Fig. 9 shows a schematic flow chart of a review method in the embodiment of the present application.

The review method can be applied to a review node in a blockchain system, such as the review node in the aforementioned fig. 3 embodiment or fig. 6 embodiment. Therefore, the technical features of the specific implementation can be referred to the previous embodiments, and are not repeated herein.

The evaluation method comprises the following steps:

step S901: the review board formed by each review node in the block chain system reviews the transaction and/or the problems occurring in the blocks;

step S902: penalizing the working node causing the problem.

For example, the wrong member is removed, the qualification and/or the rights of the wrong member are reduced, and the like.

The user node 1000 comprises a communicator 1001, a memory 1002 and a processor 1003, the communicator 1001 being configured to communicate with an external network. The memory 1002 stores a computer program that can be executed on the processor 1003, and the processor 1003, when executing the computer program, is implemented as a working node, such as a transaction processing node, a block output node, and a review node, in the embodiment of fig. 3 or fig. 6; or to perform steps in a transaction processing method as shown in the embodiment of figure 7; or to perform the steps in the block-out method as shown in the embodiment of fig. 8; or perform the steps in the review method as shown in the embodiment of fig. 9.

In some examples, the communicator 1001 may include a wired communication circuit module including a network card capable of networking, for example, and/or a wireless communication circuit module including at least one of a WiFi module, a 2G/3G/4G/5G module, a bluetooth module, and the like capable of networking.

The Memory 1002 may comprise high-speed RAM Memory, and may also include Non-volatile Memory (Non-volatile Memory), such as at least one disk Memory.

The processor 1003 may be a combination that implements a computing function, such as a combination including one or more microprocessors, Digital Signal Processing (DSP), ASIC, or the like.

In some examples, the user nodes 1000 may be implemented in, for example, a server group, a desktop, a laptop, a smartphone, a tablet, a smart band, a smart watch, or other smart devices, or a distributed processing system formed by the smart devices being communicatively connected, and each user node 1000 is installed with a block chain software program and communicates with each other to form a block chain system.

Embodiments of the present application may also provide a computer-readable storage medium, on which a computer program is stored, where the computer program runs functions implemented as a working node in the embodiment of fig. 3 or the embodiment of fig. 6, such as functions of a transaction processing node, a block output node, and a review node; or to perform steps in a transaction processing method as shown in the embodiment of figure 7; or to perform the steps in the block-out method as shown in the embodiment of fig. 8; or perform the steps in the review method as shown in the embodiment of fig. 9.

That is, the above-described functions, method steps are implemented as software or computer code storable in a recording medium such as a CD ROM, a RAM, a floppy disk, a hard disk, or a magneto-optical disk, or computer code originally stored in a remote recording medium or a non-transitory machine-readable medium downloaded through a network and to be stored in a local recording medium, so that the method described herein can be stored in such software processes on the recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware such as an ASIC or FPGA.

Although the embodiments of the present invention are disclosed above, the present invention is not limited thereto. Various changes and modifications may be effected by one skilled in the art without departing from the spirit and scope of the embodiments of the invention as defined in the appended claims.

Claims

1. A blockchain system, comprising:

the transaction processing node is used for processing or verifying transactions; when the first transaction processing node is used as a trader to process a transaction to form a transaction processing result, a predetermined number of second transaction processing nodes are used as verifiers to verify the transaction processing result; each transaction processing node and the transactions which are respectively responsible for processing are mapped to the consistent hash path, and each transaction processing node is responsible for processing each transaction between the consistent hash path and the previous transaction processing node;

2. The blockchain system of claim 1, wherein the traders are matched in each trading processing node according to trading membership conditions including at least one of: transaction credibility; transaction processing capabilities; and recording the inferior tracks.

3. The blockchain system of claim 2, wherein the determination of the reputation of the transaction comprises at least one of: a record of successful transactions, owned vouch-for digital assets; the judgment basis of the transaction processing capacity comprises the following steps: transaction processing speed.

4. The blockchain system of claim 1, wherein the trader is a first trading processing node on the consistent hash path that qualifies as a trader.

5. The blockchain system of claim 1 or 4, wherein each of the verifiers is a predetermined number of transaction processing nodes arranged after a trader on the consistent hash path.

6. The blockchain system of claim 1, wherein each trader processes multiple transactions in a multi-threaded manner when the transactions need to be processed.

7. The blockchain system of claim 1, wherein the trader processes the transactions to form transaction processing results comprising:

the verifier verifies the transaction processing result, including:

8. The blockchain system of claim 1, wherein the type of the working node further comprises: evaluating nodes; a plurality of the review nodes form a review board for reviewing problems with transactions and/or blocks and penalizing the work nodes causing the problems.

9. The blockchain system of claim 8, wherein each review node is selected from each work node by a delegation rights accreditation mechanism.

10. The blockchain system of claim 8, wherein the review board obtains the review results via a Byzantine fault-tolerant consensus mechanism.

11. The blockchain system of claim 8, wherein the problematic transactions and/or blocks are processed in a manner that includes at least one of:

12. The blockchain system of claim 11, wherein upon a problem with a block, if the review board determines that a blockman is in error, then punishment of a blockman; or if the review board determines that the blocking member does not make mistakes, the transaction processing node is informed to review the transactions in the block, so that the blocking member can re-block the transactions with problems after rejecting the transactions with problems, and the review board punishs the wrong transaction member.

13. The blockchain system of claim 11 or 12, wherein the transaction processing node reviews the status of the transaction, including at least one of:

14. The blockchain system of claim 13, wherein the endorsement node endorses a transaction comprising: modifying a location of the transaction in the consistent hash path such that a transaction processing node reviewing the transaction is distinct from a trader processing the transaction.

15. The blockchain system of claim 1, wherein the locking of the corresponding read operation of the working node is performed by a distributed read lock for the account to be read involved in the processing of the transaction or the verification thereof; and locking the corresponding write operation of the working node through a distributed write lock on the account needing to be written in the transaction processing or verification.

16. The blockchain system of claim 1, wherein the out-blockmaker is alternately acted upon by a plurality of out-blockworker nodes.

17. The blockchain system of claim 1 or 16, wherein each of the out-of-block nodes is selected from the work nodes through a delegation rights attestation consensus mechanism.

18. A block chain management method is characterized in that the method is applied to a block chain system comprising a plurality of nodes which are communicated with each other; the method comprises the following steps:

when a first transaction processing node of the blockchain system is used as a trader to process corresponding transactions of the transaction requests to form transaction processing results, a predetermined number of second transaction processing nodes are used as verifiers to verify the transaction processing results; each transaction processing node and the transactions which are respectively responsible for processing are mapped to the consistent hash path, and each transaction processing node is responsible for processing each transaction between the consistent hash path and the previous transaction processing node;

19. The blockchain management method of claim 18, comprising: when the transaction verification is in problem, a review board consisting of review nodes in the blockchain system conducts corresponding review.

20. The blockchain management method of claim 18, comprising: when a block verification is in problem, a review board consisting of review nodes in the block chain system conducts corresponding review.

21. A transaction processing method applied to a transaction processing node in the blockchain system according to any one of claims 1 to 17; the transaction processing method comprises the following steps:

the first transaction processing node confirms the identity of a trader according to the transaction matching and processes the transaction;

22. A block output method, applied to a block output node in the blockchain system according to any one of claims 1 to 17; the block output method comprises the following steps:

23. A review method applied to a review node in the blockchain system according to any one of claims 8 to 14; the evaluation method comprises the following steps:

penalizing the working node causing the problem.

24. A user node comprising a communicator for communicating with an external network, a memory having stored thereon a computer program executable by the processor, and a processor, characterized in that the processor, when executing the computer program, is implemented as a worker node in a blockchain system as claimed in any one of claims 1 to 17.

25. A computer-readable storage medium, on which a computer program is stored, which when executed implements a working node in a blockchain system according to any one of claims 1 to 17.