Skip to content

Instantly share code, notes, and snippets.

@anthdm
Last active February 7, 2020 16:09

Revisions

  1. Anthony De Meulemeester revised this gist Jun 7, 2018. 1 changed file with 5 additions and 0 deletions.
    5 changes: 5 additions & 0 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -13,6 +13,11 @@ Like most other BFT protocols hbbft is very well suited for the land of the wild

    HoneyBadger guarantees that all good nodes output the same set of transactions in each epoch. This makes it really interesting as we don't need to elect new leaders, the network can keep committing transactions instead of wasting time and bandwidth on leader elections. The nodes could keep track of the first output in a certain epoch by one of the consensus nodes and use that to record into a new block, ignoring identical sets in the same epoch.

    ### Tests
    ```
    ok github.com/anthdm/hbbft (cached) coverage: 73.6% of statements
    ```

    ### Is this code bug-free?
    I would be a rock-superstar if it was, but this code is fresh and will most likely need more community adoption and in-depth stress testing in real-world situations to be stamped as "rock solid".

  2. Anthony De Meulemeester revised this gist Jun 2, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -27,7 +27,7 @@ It's possible that during primetime the nodes will be under heavy load --when a
    >Another way that can enhance autoscaling is to dynamically scale up the TX verification worker pool. Both approaches can work together to handle high amounts of load on the node.
    ### Transaction flow
    1. A node get's a receives a new transaction from a client.
    1. One node receives a new transaction from a client.
    2. This transactions will feed in to the TX verification worker pool where a random worker will pick it up and verifies the transaction.
    3. After verification the transaction will be inserted in to the mempool of the node and pushed on top of the hbbft buffer.
    4. hbbft engine will propose a random batch transactions from its buffer.
  3. Anthony De Meulemeester revised this gist Jun 2, 2018. 1 changed file with 3 additions and 2 deletions.
    5 changes: 3 additions & 2 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -41,6 +41,7 @@ It's possible that during primetime the nodes will be under heavy load --when a
    - number of nodes 4
    - tx delay 2ms
    - batch size 600
    - tx worker pool size 4

    ```
    ===============================================
    @@ -81,9 +82,9 @@ throughput 2174 TX/S
    ```

    ### Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions. The liveness the algorithm guarantees is rock solid --no more 10 minutes+ block delays ^^--.
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions. However the liveness that the algorithm guarantees when nodes are faulty is rock solid --no more 10 minutes+ block delays--.

    ### Some Benches
    ### Benches pure on the algorithm
    Keep in mind that these are benches for the algorithm. Real world implementation will suffer by couple of variables:
    - number of carrier nodes
    - TX verification / processing on the underlying node
  4. Anthony De Meulemeester revised this gist Jun 2, 2018. 1 changed file with 43 additions and 0 deletions.
    43 changes: 43 additions & 0 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -37,6 +37,49 @@ It's possible that during primetime the nodes will be under heavy load --when a
    ### Transaction flow diagram
    <img src="https://raw.githubusercontent.com/anthdm/hbbft/master/assets/tx_stream_hbbft.png">

    ### Simulation benchmarks
    - number of nodes 4
    - tx delay 2ms
    - batch size 600

    ```
    ===============================================
    SERVER (1)
    commited 70270 transactions over 33.62288822s
    throughput 2129 TX/S
    ===============================================
    ===============================================
    SERVER (1)
    commited 75010 transactions over 35.772351082s
    throughput 2143 TX/S
    ===============================================
    ===============================================
    SERVER (1)
    commited 80632 transactions over 38.512462328s
    throughput 2121 TX/S
    ===============================================
    ===============================================
    SERVER (1)
    commited 85472 transactions over 40.466456374s
    throughput 2136 TX/S
    ===============================================
    ===============================================
    SERVER (1)
    commited 89657 transactions over 42.20158124s
    throughput 2134 TX/S
    ===============================================
    ===============================================
    SERVER (1)
    commited 93493 transactions over 43.843495793s
    throughput 2174 TX/S
    ===============================================
    ```

    ### Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions. The liveness the algorithm guarantees is rock solid --no more 10 minutes+ block delays ^^--.

  5. Anthony De Meulemeester revised this gist Jun 2, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -35,7 +35,7 @@ It's possible that during primetime the nodes will be under heavy load --when a
    6. All good / honest nodes will end up with the same commit log.

    ### Transaction flow diagram
    <img src="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.png?raw=true">
    <img src="https://raw.githubusercontent.com/anthdm/hbbft/master/assets/tx_stream_hbbft.png">

    ### Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions. The liveness the algorithm guarantees is rock solid --no more 10 minutes+ block delays ^^--.
  6. Anthony De Meulemeester revised this gist Jun 2, 2018. 1 changed file with 1 addition and 12 deletions.
    13 changes: 1 addition & 12 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -35,22 +35,11 @@ It's possible that during primetime the nodes will be under heavy load --when a
    6. All good / honest nodes will end up with the same commit log.

    ### Transaction flow diagram
    <object data="https://raw.githubusercontent.com/anthdm/hbbft/79fdb2a189be024fc57d37bace007621f29a2aee/assets/tx_stream_hbbft.pdf" type="application/pdf" width="700px" height="700px">
    <embed src="https://raw.githubusercontent.com/anthdm/hbbft/79fdb2a189be024fc57d37bace007621f29a2aee/assets/tx_stream_hbbft.pdf">
    This browser does not support PDFs. Please download the PDF to view it: <a href="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf">Download PDF</a>.</p>
    </embed>
    </object>
    <img src="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.png?raw=true">

    ### Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions. The liveness the algorithm guarantees is rock solid --no more 10 minutes+ block delays ^^--.

    ### What will be done in the next coming weeks?
    - Implement an interface for serializing and deserializing transaction, so users can roll their own serializer for transactions.
    - Full working real-world example [consenter](https://github.com/anthdm/consenter)
    - Threshold encryption (security layer)
    - Very in-depth tests and adversary simulations.
    - Further improve performance

    ### Some Benches
    Keep in mind that these are benches for the algorithm. Real world implementation will suffer by couple of variables:
    - number of carrier nodes
  7. Anthony De Meulemeester revised this gist Jun 2, 2018. 1 changed file with 2 additions and 3 deletions.
    5 changes: 2 additions & 3 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -35,9 +35,8 @@ It's possible that during primetime the nodes will be under heavy load --when a
    6. All good / honest nodes will end up with the same commit log.

    ### Transaction flow diagram
    <img src="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf">
    <object data="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf" type="application/pdf" width="700px" height="700px">
    <embed src="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf">
    <object data="https://raw.githubusercontent.com/anthdm/hbbft/79fdb2a189be024fc57d37bace007621f29a2aee/assets/tx_stream_hbbft.pdf" type="application/pdf" width="700px" height="700px">
    <embed src="https://raw.githubusercontent.com/anthdm/hbbft/79fdb2a189be024fc57d37bace007621f29a2aee/assets/tx_stream_hbbft.pdf">
    This browser does not support PDFs. Please download the PDF to view it: <a href="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf">Download PDF</a>.</p>
    </embed>
    </object>
  8. Anthony De Meulemeester revised this gist Jun 2, 2018. 1 changed file with 21 additions and 0 deletions.
    21 changes: 21 additions & 0 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -21,6 +21,27 @@ I added an abstract Transport interface which should make it very easy to implem

    Consenter will be used for testing hbbft in a more realistic scenario [consenter](https://github.com/anthdm/consenter)

    ### Autoscaling with dynamic batch sizing.
    It's possible that during primetime the nodes will be under heavy load --when a token sale is happening for example--. To handle this peak we can make use of dynamic batch sizing. In hbbft the length of the unbounded transaction buffer `len(buf)` is a very good metric for this. To enable autoscaling to a certain point we can measure the length of the buffer over a specified number of epochs `N`. When `N` is reached and batch size `B` reaches a threshold `T` we can dynamically scale up the batch size hence increasing the throughput of the node. It's also important to make sure that length of the buffer never reaches 0. The implementation of hbbft as of today will pause and poll for new transactions in the buffer before it will propose a new batch which will hit performance. Ideally is the length of the buffer between `> B / 2 and < B`. When the length of the buffer is too high we need to scale `B` down.

    >Another way that can enhance autoscaling is to dynamically scale up the TX verification worker pool. Both approaches can work together to handle high amounts of load on the node.
    ### Transaction flow
    1. A node get's a receives a new transaction from a client.
    2. This transactions will feed in to the TX verification worker pool where a random worker will pick it up and verifies the transaction.
    3. After verification the transaction will be inserted in to the mempool of the node and pushed on top of the hbbft buffer.
    4. hbbft engine will propose a random batch transactions from its buffer.
    5. The node will receive output from the hbbft engine. If the transaction is in our mempool we can directly commit the transaction. Otherwise we need to perform verification and feed this transaction to the TX worker pool. After verification the transaction can be commited and appended to the commit log.
    6. All good / honest nodes will end up with the same commit log.

    ### Transaction flow diagram
    <img src="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf">
    <object data="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf" type="application/pdf" width="700px" height="700px">
    <embed src="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf">
    This browser does not support PDFs. Please download the PDF to view it: <a href="https://github.com/anthdm/hbbft/blob/master/assets/tx_stream_hbbft.pdf">Download PDF</a>.</p>
    </embed>
    </object>

    ### Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions. The liveness the algorithm guarantees is rock solid --no more 10 minutes+ block delays ^^--.

  9. Anthony De Meulemeester revised this gist May 27, 2018. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -19,12 +19,14 @@ I would be a rock-superstar if it was, but this code is fresh and will most like
    ### Additions
    I added an abstract Transport interface which should make it very easy to implement custom transports. I currently implemented `LocalTransport` for testing.

    Consenter will be used for testing hbbft in a more realistic scenario [consenter](https://github.com/anthdm/consenter)

    ### Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions. The liveness the algorithm guarantees is rock solid --no more 10 minutes+ block delays ^^--.

    ### What will be done in the next coming weeks?
    - Implement an interface for serializing and deserializing transaction, so users can roll their own serializer for transactions.
    - Full working real-world example (mini blockchain)
    - Full working real-world example [consenter](https://github.com/anthdm/consenter)
    - Threshold encryption (security layer)
    - Very in-depth tests and adversary simulations.
    - Further improve performance
  10. Anthony De Meulemeester revised this gist May 25, 2018. 1 changed file with 6 additions and 0 deletions.
    6 changes: 6 additions & 0 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -30,6 +30,12 @@ The performance of hbbft is very good for small to medium size networks, adding
    - Further improve performance

    ### Some Benches
    Keep in mind that these are benches for the algorithm. Real world implementation will suffer by couple of variables:
    - number of carrier nodes
    - TX verification / processing on the underlying node
    - Server architecture
    - ..

    ```
    2018/05/25 22:06:00 Starting benchmark 4 nodes 128 tx size 100 batch size over 5 seconds...
    2018/05/25 22:06:05 node (0) processed a total of (117010) transactions in 5 seconds [ 23402 tx/s ]
  11. Anthony De Meulemeester revised this gist May 25, 2018. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -19,17 +19,17 @@ I would be a rock-superstar if it was, but this code is fresh and will most like
    ### Additions
    I added an abstract Transport interface which should make it very easy to implement custom transports. I currently implemented `LocalTransport` for testing.

    Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions.
    ### Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions. The liveness the algorithm guarantees is rock solid --no more 10 minutes+ block delays ^^--.

    What will be done in the next coming weeks?
    ### What will be done in the next coming weeks?
    - Implement an interface for serializing and deserializing transaction, so users can roll their own serializer for transactions.
    - Full working real-world example (mini blockchain)
    - Threshold encryption (security layer)
    - Very in-depth tests and adversary simulations.
    - Further improve performance

    Some Benches
    ### Some Benches
    ```
    2018/05/25 22:06:00 Starting benchmark 4 nodes 128 tx size 100 batch size over 5 seconds...
    2018/05/25 22:06:05 node (0) processed a total of (117010) transactions in 5 seconds [ 23402 tx/s ]
  12. Anthony De Meulemeester revised this gist May 25, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -11,7 +11,7 @@ Like most other BFT protocols hbbft is very well suited for the land of the wild
    - Asynchronous common subset (acs.go)
    - HoneyBadger protocol (honey_badger.go)

    HoneyBadger guarantees that all good nodes output the same set of transactions in each epoch. This makes it really interesting as we don't need to elect new leaders, the network can keep committing transactions instead of wasting time and bandwidth on leader elections. The nodes could keep track of the first output in a certain epoch by one of the consensus nodes and use that to record into a new block.
    HoneyBadger guarantees that all good nodes output the same set of transactions in each epoch. This makes it really interesting as we don't need to elect new leaders, the network can keep committing transactions instead of wasting time and bandwidth on leader elections. The nodes could keep track of the first output in a certain epoch by one of the consensus nodes and use that to record into a new block, ignoring identical sets in the same epoch.

    ### Is this code bug-free?
    I would be a rock-superstar if it was, but this code is fresh and will most likely need more community adoption and in-depth stress testing in real-world situations to be stamped as "rock solid".
  13. Anthony De Meulemeester revised this gist May 25, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@ Like I promised, hereby my official submission for the CoZ bounty, which contain
    The repository can be found [here](https://github.com/anthdm/hbbft).

    ### Why honey badger as the submission?
    Like most other BFT protocols hbbft is very well suited for the land of the wild --which in my opinion the crypto landscape is as today-- it guarantees liveness of the network even when nodes are behaving faulty. But what intrigued me the most is the how its constructed. The hbbft algorithm contains 4 protocols which I implemented in modular building blocks. These protocols can be separately tested and implemented.
    Like most other BFT protocols hbbft is very well suited for the land of the wild --which in my opinion the crypto landscape is as today-- it guarantees liveness of the network even when nodes are behaving faulty. But what intrigued me the most is how its constructed --which comes at a high implementation cost in time and effort--. The hbbft algorithm contains 4 protocols which I implemented in modular building blocks. These protocols can be separately tested and implemented.

    - Reliable broadcast algorithm (rbc.go)
    - Byzantine binary agreement (bba.go)
  14. Anthony De Meulemeester revised this gist May 25, 2018. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,8 @@
    # The Honey Badger of BFT Protocols
    Like I promised, hereby my official submission for the CoZ bounty, which contains a full and practical implementation of the HoneyBadger algorithm as described in the paper. All sub-protocols are tested and implemented in the top-level HoneyBadger protocol.

    The repository can be found [here](https://github.com/anthdm/hbbft).

    ### Why honey badger as the submission?
    Like most other BFT protocols hbbft is very well suited for the land of the wild --which in my opinion the crypto landscape is as today-- it guarantees liveness of the network even when nodes are behaving faulty. But what intrigued me the most is the how its constructed. The hbbft algorithm contains 4 protocols which I implemented in modular building blocks. These protocols can be separately tested and implemented.

  15. Anthony De Meulemeester created this gist May 25, 2018.
    66 changes: 66 additions & 0 deletions coz_bounty_anthdm_hbbft.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,66 @@
    # The Honey Badger of BFT Protocols
    Like I promised, hereby my official submission for the CoZ bounty, which contains a full and practical implementation of the HoneyBadger algorithm as described in the paper. All sub-protocols are tested and implemented in the top-level HoneyBadger protocol.

    ### Why honey badger as the submission?
    Like most other BFT protocols hbbft is very well suited for the land of the wild --which in my opinion the crypto landscape is as today-- it guarantees liveness of the network even when nodes are behaving faulty. But what intrigued me the most is the how its constructed. The hbbft algorithm contains 4 protocols which I implemented in modular building blocks. These protocols can be separately tested and implemented.

    - Reliable broadcast algorithm (rbc.go)
    - Byzantine binary agreement (bba.go)
    - Asynchronous common subset (acs.go)
    - HoneyBadger protocol (honey_badger.go)

    HoneyBadger guarantees that all good nodes output the same set of transactions in each epoch. This makes it really interesting as we don't need to elect new leaders, the network can keep committing transactions instead of wasting time and bandwidth on leader elections. The nodes could keep track of the first output in a certain epoch by one of the consensus nodes and use that to record into a new block.

    ### Is this code bug-free?
    I would be a rock-superstar if it was, but this code is fresh and will most likely need more community adoption and in-depth stress testing in real-world situations to be stamped as "rock solid".

    ### Additions
    I added an abstract Transport interface which should make it very easy to implement custom transports. I currently implemented `LocalTransport` for testing.

    Conclusion
    The performance of hbbft is very good for small to medium size networks, adding more nodes impact performance drastically, we can counter this by increasing the batch size, but this approach will not scale infinitely. One round of HoneyBadger consensus can contain around 80 messages that are exchanged by participants in the network before reaching consensus on a set of transactions.

    What will be done in the next coming weeks?
    - Implement an interface for serializing and deserializing transaction, so users can roll their own serializer for transactions.
    - Full working real-world example (mini blockchain)
    - Threshold encryption (security layer)
    - Very in-depth tests and adversary simulations.
    - Further improve performance

    Some Benches
    ```
    2018/05/25 22:06:00 Starting benchmark 4 nodes 128 tx size 100 batch size over 5 seconds...
    2018/05/25 22:06:05 node (0) processed a total of (117010) transactions in 5 seconds [ 23402 tx/s ]
    2018/05/25 22:06:05 node (1) processed a total of (116923) transactions in 5 seconds [ 23384 tx/s ]
    2018/05/25 22:06:05 node (2) processed a total of (117010) transactions in 5 seconds [ 23402 tx/s ]
    2018/05/25 22:06:05 node (3) processed a total of (116923) transactions in 5 seconds [ 23384 tx/s ]
    2018/05/25 22:06:05 Starting benchmark 6 nodes 128 tx size 200 batch size over 5 seconds...
    2018/05/25 22:06:10 node (0) processed a total of (89585) transactions in 5 seconds [ 17917 tx/s ]
    2018/05/25 22:06:10 node (1) processed a total of (89585) transactions in 5 seconds [ 17917 tx/s ]
    2018/05/25 22:06:10 node (2) processed a total of (89585) transactions in 5 seconds [ 17917 tx/s ]
    2018/05/25 22:06:10 node (3) processed a total of (89585) transactions in 5 seconds [ 17917 tx/s ]
    2018/05/25 22:06:10 node (4) processed a total of (89585) transactions in 5 seconds [ 17917 tx/s ]
    2018/05/25 22:06:10 node (5) processed a total of (89585) transactions in 5 seconds [ 17917 tx/s ]
    2018/05/25 22:06:10 Starting benchmark 8 nodes 128 tx size 400 batch size over 5 seconds...
    2018/05/25 22:06:15 node (0) processed a total of (72259) transactions in 5 seconds [ 14451 tx/s ]
    2018/05/25 22:06:15 node (1) processed a total of (72259) transactions in 5 seconds [ 14451 tx/s ]
    2018/05/25 22:06:15 node (2) processed a total of (72259) transactions in 5 seconds [ 14451 tx/s ]
    2018/05/25 22:06:15 node (3) processed a total of (72259) transactions in 5 seconds [ 14451 tx/s ]
    2018/05/25 22:06:15 node (4) processed a total of (72259) transactions in 5 seconds [ 14451 tx/s ]
    2018/05/25 22:06:15 node (5) processed a total of (72259) transactions in 5 seconds [ 14451 tx/s ]
    2018/05/25 22:06:15 node (6) processed a total of (72259) transactions in 5 seconds [ 14451 tx/s ]
    2018/05/25 22:06:15 node (7) processed a total of (72259) transactions in 5 seconds [ 14451 tx/s ]
    2018/05/25 22:06:15 Starting benchmark 12 nodes 128 tx size 1000 batch size over 5 seconds...
    2018/05/25 22:06:20 node (0) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (1) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (2) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (3) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (4) processed a total of (53504) transactions in 5 seconds [ 10700 tx/s ]
    2018/05/25 22:06:20 node (5) processed a total of (53504) transactions in 5 seconds [ 10700 tx/s ]
    2018/05/25 22:06:20 node (6) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (7) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (8) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (9) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (10) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    2018/05/25 22:06:20 node (11) processed a total of (52542) transactions in 5 seconds [ 10508 tx/s ]
    ```