Updates from the Development Team on Speed/Load Test.

Dear Credits Community,

As you may well know, the team continues to work hard so an outstanding result will be achieved when we all participate in the public speed/load test.

What did we do over the last week?

We have launched a number of transaction generators to generate transactions for the upcoming speed/load test. The transaction generators are NOT on the same machine as a Credits' node (the Validator) but are on a completely separate machine that communicates with the Validators over the public network. We are doing this so that the transactions per second (TPS) achieved during the public speed/load test will be 100% authentic. The TPS achieved will NOT be "skewed" by running the transaction generator and the node software on the same machine.

We are doing this to mimic real-world software application scenarios built on a blockchain.

Also, remember too, we are achieving this WITHOUT sharding.

What did we want to achieve?

Last week's goal was to find out the "real world" TPS speed of the Credits blockchain with block formation times of one second.
The hardware used for this speed/load test is outlined here. 

To determine this TPS speed, we slowly increased the output of the transaction generators until the block formation time reached one second. The speed reached when this occurred was 20k TPS. At speeds above 20k TPS, the block formation time begins to grow steadily.

The Validator nodes used in the above tests include several improvements, including signature verification with parallelism. We are still testing these upgraded nodes, and if it continues that no violations are found, they will be merged into the code running on the mainnet.

Did we find any issues?

During testing, we found that ramping up the number of transactions pushed onto the network, led to a delay of their formation due to the increased number of transactions, which resulted in the rising transmission time. Therefore, some transactions were not reaching the blockchain. This phenomenon was consistently repeated.

We studied this issue and by the end of the week, we did manage to eliminate the delay of packet formation, but the speed of their distribution is low at high transaction generator speeds.

Did we change anything?

We did make one change to a default parameter of the Validator nodes used in the test, that resulted in the following: if a node is sent a block or a packet with parameters that do not satisfy its settings, the node considers the sending node to be an intruder and adds it to the ban list.

What are we doing now?

We are working on the selection of the optimal parameters of the transport environment to ensure the maximum speed of packet distribution is achieved.

What will we be doing over the next week?

In the coming week, the main emphasis will be on studying the mechanisms of block formation and to improve upon this.

As a matter of interest, and using the hardware configuration referenced above, it takes about 0.35 to 0.40 seconds to check 20k transactions on the current hardware when the block formation time is around 0.90 to 1.00 seconds.

The next update on our progress to follow soon!