Final Report on the Public Test of Locus Chain
<Final Report on the Public Test of Locus Chain>
* Test Period
October 22nd (Tuesday) ~ October 24th (Thursday)
* Overview
Public test of Locus Chain’s testnet (version which does not include Sharding)
* Participation Status
◈ On the first day of the test from 14:00 to 15:00 based on the time in Korea, node rebooting of the entire boot nodes and ledger initialization occurred -> It was for the purpose of checking how the peer information propagation and synchronization between nodes occur when the boot nodes are rebooted and the ledger is initialized at the same time, and then re-run automatically.
* Description of Each Tested Function
(1) AWTC-BFT Consensus: Operation of the deterministic consensus system on DAG : BFT (Byzantine Fault Tolerance) It has been confirmed that the operation of deterministic consensus is accurate and system load almost did not occur.
It operated normally in all the steps from the committee election of each round to the transaction confirmation. It has also been confirmed that the transactions become recorded completely in parallel on the AWTC ledger.
(2) Whether or not the node runs normally on the general PC : It operates normally on a laptop with low performance. Although it was informed in the guide, there was a question that asked if it is possible to run the node on mobile devices.
The CPU resource usage did not exceed 5% and the RAM resource usage did not exceed 30mb ~ 50mb -> These values may vary depending on computer specifications, but with these values, running the nodes do not affect the tasks.
(3) Synchronization of ledger : The majority operated normally
Average time of initial ledger synchronization during normal operation : within 1 minute
A situation occurred every day in which it took at least 10 minutes to synchronize the ledger of around 2~3 nodes. -> There was a feedback that mentioned it takes longer for initial ledger synchronization if the node becomes run initially in an area with slow network. This is a problem that can be resolved with the application of Sharding. Locus Chain’s ledger synchronization is very fast compared to that of Ethereum, which can take a few days.
(4) Single Transaction Processing Speed : The single transaction processing time (average value per day) was 0.18 ~ 0.23 second. It has been confirmed that this time value does not increase by a lot when the number of nodes and transactions increase. It appears the error in the test occurred due to the network speed. To assume the international standard network speed in reality, it seems 2-3 seconds of difference in the processing speed does not hold substantial significance. Accordingly, we concluded that in Locus Chain, the single transaction processing speed stays in a steady speed even when the volume of transactions substantially increase, under the same network speed.
(5) Node connection setting, Coin transfer, Activate, Explorer : The majority of functions operated normally without any reports on errors. However, there were some questions asking for clarification about the message of the node. Also, two questions were on how the users could not understand the ‘Activate’ concept when sending the coins. -> It is necessary to explain the Activate concept of AWTC more in detail in the future.
(6) Verifiable Pruning : Verifiable Pruning operated normally every time an epoch (time when Verifiable Pruning proceeds) occurred, which contributed to maintaining the small ledger size. The ledger size that was measured using Windows explorer was around 2Mbyte (1 Epoch interval = occurs every 1 hour). Let’s take an example to calculate the maximum ledger size in the environment with actual use. Under the assumption that a blockchain processes 4,000 TPS, has transactions with each transaction the size of 0.5 kb, divides the network into 10 shards, and considers 1 Epoch interval as 1 day,
the maximum ledger size per node is 0.5kB/Tx * 4kTx/sec * 3.6ksec/hour * 24hour/day ÷ 10 shards = 17.28GB/day (per shard). Since can optimize the data storage before 1 Epoch, it may be feasible to keep the actual maximum ledger size per node within 10GB.
(7) Verification function of data forging and manipulation : The verification function of files ran normally even after the ledger size decreased due to Verifiable Pruning that took place. We believe we have appealed the scarcity and excellence of this technology to the professionals.
(8) Others : Even though the majority of the users who participated in the test are familiar with the blockchain ledger structure, they are not familiar with the AWTC ledger structure. Thus, it seems the AWTC ledger structure (suitable for high speed transaction processing, collisions almost do not occur and has excellent scalability) needs to be explained more in detail.
* Comprehensive Summary
In this public test, the fast transaction processing speed, secured through the AWTC ledger structure, was maintained without being interrupted by the BFT consensus algorithm. Also, the single transaction processing time was maintained and did not slow down even when the number of nodes and transactions increased. The Verifiable Pruning function operated successfully as well within the entire testing period, which retained the small ledger size. It was possible for the computer resources to operate the nodes without majorly becoming occupied. Overall, all the functions prepared for this test operated effectively without any special errors.
Comprehensively, we were able to receive the desired test results through this test. Regardless of the application of Sharding, we believe Locus Chain will become the world’s first practically usable blockchain if it steps through the code stabilization process.
