# NeuChain+: A Sharding Permissioned Blockchain System with Ordering-Free Consensus
## 7 Evaluation
### Overall Performance  
In order to evaluate the overall improvement of system performance by sharding, NeuChain+ compares the peak throughput, corresponding abort rate, and latency with its competitors under the workloads of SmallBank, YCSB-A, YCSB-B, and YCSB-C. The experimental results are the average of three experiments.  
As shown in Figure 6, benefiting from the scalability of sharding and the efficient cross-shard transaction processing protocol _cross-reserve_, the throughput of NeuChain+ reached 146.65 kTPS under SmallBank workload, which is approximately \(1.7\times\) that of NeuChain, far exceeding other comparison systems. In state-sharding blockchains [27; 28; 29; 30; 31; 34; 37; 38; 39], there are two unavoidable sources of communication overhead resulting in higher latency compared to non-sharding blockchain systems. One is that cross-shard transactions need to obtain the required read sets from remote shards, and the other is that cross-shard transactions require intershard coordination to make decisions on whether to commit. However, NeuChain+ eliminates intershard coordination (Section 5) and optimizes read set transmission (Section 4.2), achieving a latency of approximately 0.18 s under the SmallBank workload, slightly higher than NeuChain but still at the same level as the most state-of-the-art nonsharding blockchains and much lower than the sharding blockchain Meepo. The abort rate of NeuChain+ is higher than that of other blockchains, with approximately 8% of transactions being aborted under the SmallBank workload, due to two reasons. First, in the SmallBank workload, over 80% of operations are write operations. Under deterministic concurrency control, some transactions are deterministically aborted, which will inevitably increase the abort rate while providing excellent throughput. Second, after sharding, the total amount of accounts is divided evenly among shards, which increases the probability of transaction conflicts. Notably, Basil is essentially a BFT-distributed database. Since it does not need to generate blocks, transactions can be returned immediately after execution, unlike blockchain systems that must wait for the entire block's transactions to be executed before returning. As a result, its latency is only 0.007 s under the SmallBank workload.  
Figure 6: Throughput and latency performance comparison. (**a**) SmallBank workload; (**b**) YCSB-A workload; (**c**) YCSB-B workload; (**d**) YCSB-C workload.  
Under the YCSB-A workload, although the number of records is 10\(\times\) that of SmallBank and the proportion of write operations is lower than SmallBank, the use of Zipf distribution creates hot records. As a result, the system's abort rate increases. Under the YCSB-B workload, the abort rate significantly decreases due to the mere 5% write proportion of operations. Additionally, because read operations are considerably lighter than write operations, the throughput of each system increases while the latency decreases. Under the YCSB-C workload, since all transactions are read-only, no transaction will be aborted due to conflicts. In NeuChain+, the absence of transactions with remote read-write dependencies eliminates the need for the read set transmission, resulting in significantly reduced latency compared to other workloads.