WO2018232490A1

WO2018232490A1 - Multilevel queue based transaction traffic shaping for blockchains

Info

Publication number: WO2018232490A1
Application number: PCT/CA2018/000125
Authority: WO
Inventors: Enyan DENG
Original assignee: Zeu Crypto Networks Inc.
Priority date: 2017-06-22
Filing date: 2018-06-20
Publication date: 2018-12-27
Also published as: CN107241279A

Abstract

A multilevel queue based blockchain transaction traffic shaping method is disclosed. The method includes receiving a transaction request at the blockchain from a client; inserting the transaction into the first-level queue, and using the transaction's ID for hash calculation; performing a modulo operation on the hash value according to the number of second-level queues, and inserting the transaction into a corresponding second-level queue according to the remainder of the modulo operation; and transitioning from the second level queue to a third level queue, during which transaction rate-limiting is enforced. A rate-limit strategy sets the size of the third-level queue to adjust the rate. A scheduler, timely adjusts the size of the queue to handle the incoming burst requests based on processing power. Concurrent processing and load balancing are utilized to handle bursts of transactions, to effectively improve the stability of the blockchain system.

Description

Multilevel Queue Based Transaction Traffic Shaping for Blockchains Technical Field

[0001] The present invention relates generally to blockchain technology and in particular to blockchain systems that utilize transaction traffic shaping.

Background Art

[0002] In the last few years, blockchain technology has made great strides, and the speed of blockchain transaction processing has greatly improved. Blockchain is a distributed database system involving a networked set of computing devices called nodes. It has often been understood as distributed ledger technology jointly maintained by multiple nodes. It can be characterized as highly tamper-resistant, difficult to forge or counterfeit, and traceable. Blockchain records all transactions that have ever occurred on the blockchain.

[0003] There have been several generations of blockchain technology today. Bitcoin is an example of the first generation of blockchain technology, in which only historical transaction information is recorded on a distributed ledger, and no account information is recorded for the account balance. Further development of blockchain technology has led to what may be called the second generation of blockchain technology, which is represented by Ethereum. The third of generation blockchain technology is based on the concept of a full ledger concept and chain code, and adopts the design of the private or permissioned blockchain.

[0004] Third-generation blockchain technology, such as TianDe Blockchain, can process tens of thousands of transactions per second. However, for commercial applications often characterized by sudden peaks of the incoming transaction volume, such as the Double 1 1 Day or Single's Day online shopping event which reached a peak rate of 12 million payments per second, current blockchain transaction processing speed still cannot meet the processing demand paused by the burst of traffic. The instantaneous trading volume increase may cause the entire blockchain system to at least temporarily shutdown, resulting in significant loss. [0005] In order to tackle the above bursty traffic problem in conventional high-concurrency systems, the transaction processing capacity of the system is typically increased by using caching, downgrading, and flow control, so that the burst traffic is temporarily blocked, the system is load-balanced and the rate of concurrent access and requests is limited. Such measures and others are used to protect the system.

[0006] However, while traditional high-concurrency systems essentially have a primary- replica or primary-secondary system architecture, blockchain systems use a completely different architecture. As a result, traditional solutions cannot be effectively used to meet requirements of the blockchain system. The is thus a need for a blockchain technology platform capable of handling bursts of transactions.

Summary of Invention

[0007] In accordance with one aspect of the present invention, there is provided a method of shaping transaction traffic in a blockchain utilizing a multilevel queue system. The method includes inserting blockchain transactions into first-level queue of the multilevel queue system; inserting transactions from the first-level queue, into a plurality of second level queues of the multilevel queue system; inserting transactions from the second-level queues into a plurality of corresponding third-level queues of the multilevel queue system; and retrieving transactions from the third level queues, for consensus voting.

[0008] In accordance with another aspect of the present invention, there is provided a blockchain system including a plurality of nodes implementing a multilevel queue system, a consensus thread, and a scheduler. The multilevel queue system includes a first-level queue, a plurality of second level queues and a plurality of third level queues. The scheduler inserts blockchain transactions into the first-level queue; transactions from the first-level queue, into a plurality of second level queues; and finally inserts transactions from the second-level queues into a plurality of corresponding third-level queues. The consensus thread retrieves transactions from the third level queues for consensus voting. [0009] In accordance with yet another aspect of the present invention, there is provided a blockchain system including a plurality of nodes, implementing a multilevel queue system having N levels where N > 2, a consensus thread, and a scheduler. The scheduler inserts blockchain transactions into the first-level queue; and iteratively inserts transactions from the nth level queue into a plurality of n+l^st level queues for n < N. The consensus thread retrieves transactions from the N^th level queues for consensus voting.

Brief Description of Drawings

[0010] In the figures, which illustrate by way of example only, embodiments of the present invention:

[0011] FIG. 1 is a simplified block diagram of the internal storage a first- level queue, for a blockchain exemplary of an embodiment of the present invention;

[0012] FIG. 2 is a simplified block diagram of blockchain transactions divided into two channels and stored in second-level queues;

[0013] FIG. 3 is a simplified block diagram of the internal storage of third-level queues implementing traffic rate-limiting;

[0014] FIG. 4 is a simplified block diagram of the transaction data flow in a multilevel queue based blockchain system, in accordance with one embodiment;

[0015] FIG. 5 is a schematic diagram of the blockchain transaction traffic handling without the use of multilevel queues; and

[0016] FIG. 6 is a table of example transactions taken out for blockchain consensus threads.

[0017] Specific embodiments will be described in detail, by way of example only, with reference to the attached drawings. The same reference label in the drawings identifies the same or similar elements, parts or portions thereof. Persons of skill in the art will readily understand that the drawings are not necessarily drawn to scale. Description of Embodiments

[0018] In order to equip a blockchain technology platform to handle a burst of transactions, a multilevel queue based blockchain transaction traffic shaping, which combines the characteristics of high-concurrency system and the characteristics of blockchain multi-node consensus, is presented. Embodiments of the present invention can effectively meet the efficiency requirements of a blockchain system while ensuring high concurrency, high availability and system stability.

[0019] In order to deal with the shortcoming of conventional blockchain systems in managing peak trading scenarios, embodiments of the present invention provide a multilevel queue based blockchain transaction traffic shaping system and method.

[0020] Some of the disclosed embodiments include blockchain systems, with multilevel queues, which are used to offload and restrict the transaction traffic so as to smooth out the peak traffic and effectively utilize the high concurrency processing capability of the system. A first level queue forming part of the system, includes a very large buffer for holding client-initiated transaction processing requests to ensure that transaction requests will not be discarded due to denial of access. One or more second level queue that have relatively smaller buffers are also used. The number of second-level queues may be determined by the number of available concurrent threads and system capacity. As will become apparent later, transaction requests may divide into two or more channels. Second level queues also play a role in load balancing.

[0021] In one exemplary blockchain system, each transaction is assigned, by default, with a unique transaction identifier (ID). A transaction ID hash operation is performed whereby a hash value undergoes a modulo operation where the divisor is the number of queues. The transaction is then allocated to a corresponding second level queue based on the remainder of the modulo operation. Transaction traffic shaping is performed at the second level queue and the third level queue. The traffic shaping policy adjusts the current control rate in time by setting the size of the third level queue. Adjusting the size of the queue according to the processing power of the thread in time allows the system to meet the processing requirement for the burst of traffic. [0022] Embodiments of the present invention fully utilize concurrent processing within blockchain systems to meet the processing requirements at certain sudden peak transactions. The disclosed embodiments combine load balancing technology to maximize system concurrency and help improve system stability.

[0023] In this disclosure, the use of the word "a" or "an" when used herein in conjunction with the term "comprising" may mean "one," but it is also consistent with the meaning of "one or more," "at least one" and "one or more than one." Any element expressed in the singular form also encompasses its plural form. Any element expressed in the plural form also encompasses its singular form. The term "plurality" as used herein means more than one, for example, two or more, three or more, four or more, and the like. Directional terms such as "top", "bottom", "upwards", "downwards", "vertically" and "laterally" are used for the purpose of providing relative reference only, and are not intended to suggest any limitations on how any article is to be positioned during use, or to be mounted in an assembly or relative to an environment.

[0024] The terms "comprising", "having", "including", and "containing", and grammatical variations thereof, are inclusive or open-ended and do not exclude additional, un-recited elements and/or method steps. The term "consisting essentially of when used herein in connection with a composition, use or method, denotes that additional elements, method steps or both additional elements and method steps may be present, but that these additions do not materially affect the manner in which the recited composition, method, or use functions. The term "consisting of when used herein in connection with a composition, use, or method, excludes the presence of additional elements and/or method steps.

[0025] A "blockchain" is a tamper-evident, shared digital ledger that records transactions in a public or private peer-to-peer network of computing devices. The ledger is maintained as a growing sequential chain of cryptographic hash-linked blocks. [0026] A "node" is a device on a blockchain network. The device is typically be a computer having a processor interconnected to a processor readable medium including memory, having processor readable instructions thereon.

[0027] In addition, the terms "first", "second", "third" and the like are used for descriptive purposes only and cannot be interpreted as indicating or implying relative importance.

[0028] In the description of the invention, it should also be noted that the terms "mounted", "linked" and "connected" should be interpreted in a broad sense unless explicitly defined and limited otherwise. For example, it could be fixed connection, or assembled connection, or integrally connected; either hard-wired or soft-wired; it may be directly connected or indirectly connected through an intermediary. For technical professionals, the specific meanings of the above terms in the invention may be understood in context.

[0029] In the drawings illustrating embodiments of the present invention, the same or similar reference labels correspond to the same or similar parts. In the description of the invention, it should be noted that the meaning of "a plurality of means two or more unless otherwise specified; The directions or positions of the terms "up", "down", "left", "right", "inside", "outside", "front end", "back end", "head", "tail", the orientation or positional relationship shown in the drawings is merely for the convenience of describing the invention and simplifying the description rather than indicating or implying that the indicated device or element must have a particular orientation and be constructed and operated in a particular orientation, and therefore cannot be used as a limitation of the invention.

[0030] The core blockchain system, in accordance with an exemplary embodiment, utilizes the consensus algorithm. Most private or permissioned blockchains adopt the Practical Byzantine Fault Tolerance (PBFT) algorithm, and the nodes participating in the consensus process will verify transactions and vote. Assuming that there are 3f +1 (where f - 1, 2,... ) nodes so that there are (4, 7, ...) nodes participating in the consensus, if the number of nodes voting "yes" is > 2f + 1 that is, (3,5 ...) in the blockchain system, then the transaction is considered valid, the blockchain system will store valid transactions in a block, and link the block to the tail of the blockchain.

[0031] Suppose a blockchain has four consensus nodes in the blockchain system; each node has a multilevel queue system; the queue system has two channels; and the third-level queue limit is two transactions. Then the multilevel queue system will work in accordance with the following four (4) steps:

[0032] First, blockchain transactions are inserted into the multilevel queue system. The client system respectively sends six transactions Txl, Tx2, Tx6 to the first-level queue of four nodes, and enters six transactions in a first- level queue 100 as shown in FIG. 1.

[0033] Second, blockchain transactions are divided. According to the principle of first-in- first-out (FIFO) queue, the scheduler pops the transaction from the first-level queue 100. First, Txl pops up from the queue and hash calculation is performed on its transaction identifier (ID). Suppose the transaction ID of for n^th transaction Txn is denoted TxIDn (where n=l , 2, ...).

[0034] Assuming HASH (TxIDl) = 0x0001, HASH (TxIDl) = 0x0001, HASH (TxID2) = 0x0002, HASH (TxID3) = 0x0003, HASH (TxID4) = 0x0004, HASH (TxID5) = 0x0005, and HASH (TxID6) = 0x0006, a modulo operation (denoted % or mod) is performed where the hash value is the dividend and the number of channels is the divisor, so that for Txl this yields 0x0001 % 2 = 1. Transaction Txl is thus assigned to channel 1 of the second-level queue 104. Similarly, transactions Tx2-Tx6 will be assigned to the corresponding channel (0 or 1) of the second level queues 102, 104 respectively. Transactions are diverted to channels, as shown in FIG. 2.

[0035] Third, blockchain transaction rate-limiting. In this example, the limit of the third- level queue is two transactions, the maximum number of transactions from the second-level queue to the third-level queue is two, and each third-level queue 106, 108 functions similarly to the leaky bucket algorithm to control the rate of transaction processing, to smooth out the burst transactions, as shown in FIG. 3. The number of transactions stored in the third-level queues is limited to an adjustable limit to provide rate-limiting.

[0036] Fourth, blockchain transactions retrieved from the multilevel queue system. BC (Blockchain) consensus thread takes transactions out from the third-level queue for consensus. Because there are multiple blockchain consensus threads, the blockchain consensus process can process transactions in parallel to enhance the blockchain system's ability to handle transactions.

[0037] In general, the overall process of initiating a transaction from a client 400, to a multilevel queue system, and then to BC consensus threads, is shown in FIG. 4. The depicted queue subsystem has a first-level queue 100 and second-level queues 200 and third-level queues 300.

[0038] To appreciate the role of a multilevel queue subsystem in improving blockchain system performance, consider a queue subsystem has only first-level queue 500 and no second- level or third-level queues as depicted in FIG. 5. Under such a system, two BC consensus threads 502, 504 take transactions from the first-level queue 500 for consensus. For each consensus, each thread 502, 504 takes two transactions from the queue and the BC consensus threads are in competition relationship with each other. The queue access must be mutually exclusive, as shown in FIG. 5.

[0039] Possible consequence of transactions taken out by BC Consensus Threads are as shown in the table in FIG. 6, when BC consensus threads of four nodes each obtains the above transaction sequence due to the competitive relationship, the consensus of Thread 0 on transactions TxIDl-TxID4 will fail (for failing to satisfy > 2f + 1), the transaction TxIDl-TxID4 is re-routed back to the tail of the first-level queue and ready for the next time taking out for consensus.

[0040] For multilevel queue subsystems, after the transactions are divided and rate-limited, the above problems can be effectively avoided. It can be said that dividing the transactions into multiple channels improves the consensus efficiency of the blockchain system and achieves a certain load balancing effect and maximizes the efficiency of blockchain system, while rate- limiting makes the blockchain system smooth out the burst traffic. This ensures high availability and stability of the system.

[0041] While the present invention has been described with reference to the particular illustrative embodiments, it is to be understood that the invention is not to be limited by the particular details of the embodiments described but only by the appended claims. Persons of skill in the art would understand that the implementation details of the present invention can be modified without departing from the scope of the claims.

Claims

What is claimed is:

1. A method of shaping transaction traffic in a blockchain utilizing a multilevel queue system, the method comprising:

a) inserting blockchain transactions into first-level queue of the multilevel queue system; b) inserting transactions from the first-level queue, into a plurality of second level queues of the multilevel queue system;

c) inserting transactions from the second-level queues into a plurality of corresponding third-level queues of the multilevel queue system; and

d) retrieving transactions from the third level queues, for consensus voting.

2. The method of claim 1, further comprising receiving the blockchain transactions from a client system for insertion into the first-level queue.

3. The method of claim 1, wherein each of the second-level and third-level queues belong to one of a plurality of channels, the method further comprising:

for each transaction in the first-level queue,

a) determining a hash value based on an identifier of the transaction;

b) selecting one of the plurality of channels based on the hash value; and

c) assigning the transaction to a second-level queue that belongs to the selected channel.

4. The method of claim 3, wherein said selecting one of the plurality of channels based on the hash value comprises performing a modulo operation with the number of said plurality of channels as divisor and the identifier of the transaction as dividend.

5. The method of claim 3, the number of transactions stored in the third-level queues is limited to an adjustable limit, to provide rate-limiting.

6. The method of claim 3, further comprising retrieving transactions from the third-level queues for consensus voting.

7. The method of claim 3, wherein transactions from any two different channels among said plurality channels are concurrently processed for the consensus voting thereby increasing processing efficiency of the blockchain.

8. The method of claim 5, wherein said limit smoothes out a burst said transactions thereby maintaining high availability and increased stability of the blockchain.

9. A blockchain system comprising a plurality of nodes implementing: a multilevel queue system, a consensus thread, and a scheduler; the multilevel queue system comprising first- level queue, a plurality of second level queues and a plurality of third level queues, wherein the scheduler:

a) inserts blockchain transactions into the first-level queue;

b) inserts transactions from the first-level queue, into a plurality of second level queues; and c) inserts transactions from the second-level queues into a plurality of corresponding third- level queues;

wherein the consensus thread retrieves transactions from the third level queues for consensus voting.

10. The blockchain system of claim 9, wherein the blockchain transactions are received from a client system for insertion in to the first-level queue.

1 1. The blockchain system of claim 9, wherein each of the second-level and third-level queues belong to one of a plurality of channels, wherein for each transaction in the first-level queue, the scheduler:

a) determines the hash value based on an identifier of the transaction;

b) selects one of the plurality of channels based on the hash value;

c) assigns the transaction to a second-level queue in the selected channel.

12. The blockchain system of claim 9, wherein the scheduler selects one of the plurality of channels based on the hash value by performing a modulo operation with the number of said plurality of channels as divisor and the identifier of the transaction as dividend.

13. The blockchain system of claim 1 1, wherein the third-level queues are rate-limited to an adjustable limit on number of transactions, and wherein insertion of transactions from the second-level queues into a plurality of corresponding third-level queues is limited to said adjustable limit.

14. The blockchain system of claim 1 1, wherein the consensus thread retrieves transactions from the third-level queues for consensus voting.

15. The blockchain system of claim 1 1 , wherein transactions from any two different channels among said plurality channels are concurrently processed for the consensus voting thereby increasing processing efficiency of the blockchain.

16. The blockchain system of claim 13, wherein said limit smoothes out a burst said transactions thereby maintaining high availability and increased stability of the blockchain system.

17. A blockchain system comprising a plurality of nodes, implementing a multilevel queue system having N levels where N > 2, a consensus thread, and a scheduler, wherein the scheduler:

a) inserts blockchain transactions into the first-level queue; and

b) iteratively inserts transactions from the n^th level queue, into a plurality of η+ ' level queues for n < N;

and wherein the consensus thread retrieves transactions from the N^th level queues for consensus voting.