The CREDITS blockchain platform has recorded an amazing transaction speed of 488,403 transactions per second during the Alpha version testing.
This has been thanks to a recalibration of particular parts of the platform, data storing mechanism as well as the API.
The Testing Process
The main aim for the test was to derive the system’s maximum load, checking how resistant it is towards processing numerous transactions, and resolving its issues.
Testing was done using Microsoft Hyper-V for x64-based systems with the following specs:
- Intel® Xeon® E5–2630
- 15 MB flush
- 30 GHz
- 20 GT/s Intel® QPI
- Turbo boost of 2.80 GHz
- 8 GB RAM
The MS Virtual Machine config required 29 nodes to be created along with 1 signalling server boasting processing speeds of 2.2 to 2.8 GHz. Transactions were simulated using bots with every server running Client_6300.bat and TransactionSendler.exe.
The Technicalities
Through multi-threading and node-driven asynchronous processing, the system achieved transaction consistency between 300 to 500,000 transactions per second. Factors like balance, address length, currency, digital signature availability etc. were considered.
EDS was eliminated from the equation as it added 64 bytes per transaction resulting in extra processing time. To validate nodes, a simplified version of the BFT validation algorithm was used instead of DPOS. Transaction validation was done in absence of account balance verification. The testing also did not consider transaction fees and smart contract processing.
Problems That Were Discovered and Their Solutions
Enormous hardware configurations, data transmission and processing through applied technologies, and varying network bandwidths limit the processing speed greatly. These and many other factors seriously hamper the optimisation of platform performance.
Conclusions Drawn From The Results
Transaction recording and processing is hampered by low-grade hardware
Network load also hampers speed along with the environment. In addition, other considerations necessitate implementation of big data storage frameworks.
System operations were impeded by the transaction generation relying on network connector cues for packet transmission
The problem might be solved by removing the protocol itself but at the risk of data loss during calibration. Transmissions were also hindered by the maximum size limit of 65,535 bytes. This required restriction to the aforementioned UDP Protocol limit. In turn, data loss and speeds were compensated.
Data loss was witnessed during multi-transaction processing. Turn-based and limit-oriented data processing was used to solve this. Additionally, during constant transaction streaming channels got congested. This problem was solved by changing the architecture for storing data and API.
The Bottom Line
The results obtained from the test show that the CREDITS platform has a lot of potential.
This is of great relevance to the blockchain community and the project itself. It shows that actual load processing capacity can be scaled-up to anticipated magnitude of operations.
It has been proved that the CREDITS system is capable of handling 500 thousand per second and above.
Since this is only with low-level hardware that we used, the system shows the potential for transaction processing in millions in fractions of a second. This will be done through optimisation of the programming code later on offering transaction-recording speeds at 1.302 microseconds.