# NeuChain+: A Sharding Permissioned Blockchain System with Ordering-Free Consensus
## 1 Introduction  
The applications of permissioned blockchain in scenarios like digital assets [1], supply chains [2], government services [3], and Web 3.0 [4] are becoming increasingly diverse, but the performance of existing blockchains fails to meet the demands of these high-throughput applications [5; 6; 7; 8]. For example, Hyperledger Fabric, a widely adopted permissioned blockchain, can only achieve a throughput of around 3.5 kTPS [9]. In contrast, financial applications like Visa [10] require tens of kTPS to handle peak transaction volumes [11]. Permissioned blockchains typically employ consensus protocols to ensure consistent execution results across nodes. However, most consensus protocols (e.g., PBFT [12], Raft [13]) rely on a single leader node to order all client transactions, making it inherently sequential and impossible to parallelize, limiting the overall throughput. Existing works [14; 15; 16; 17; 18; 19] address the single-node bottleneck by improving the scalability of consensus protocols. GeoBFT [20], RCC [21], and ISS [22] run multiple consensus instances concurrently to distribute the workload of the single leader node. [PERSON] [23] and the research of [PERSON] et al. [24] parallelize ordering and transaction execution to hide the ordering latency. NeuChain [25] uses deterministic transaction execution to escape strict total ordering, thereby eliminating the need for explicit transaction ordering consensus. By allowing multiple nodes to independently receive requests, the single-node ordering bottleneck is eliminated. Moreover, NeuChain benefits from deterministic concurrency control, enabling asynchronous block generation. However, all transactions must still achieve consensus and be globally replicated before execution can be completed, each node having to execute all transactions. As we can see, the above approaches, including NeuChain, do not fundamentally address the scalability issue, as transactions must be globally replicated to all nodes. Firstly, since the consensus protocols ensure that each correct node receives a transaction copy to maintain its local ledger, the total network traffic consumption increases as the number of nodes increases. Secondly, full transaction execution and ledger update are performed on each node exclusively, meaning that the throughput does not scale with increase in the total number of nodes. As shown in Figure 1a, we experimented with NeuChain to show the scalability issue (detailed setup in Section 7). When scaling the number of nodes from 4 to 16, the throughput and latency remain unchanged. Thirdly, having each node maintain the complete blockchain ledger creates significant storage overhead. As shown in Figure 1b, the storage consumption of a node in NeuChain reaches 1561 MB after running for only 60 s.  
Blockchain sharding [26] is proposed to solve the above scalability issues, where the ledger is divided into multiple disjoint shards, each maintained by a set of nodes. By distributing workloads across multiple shards, system performance scales linearly with the number of shards. However, to execute cross-shard transactions (i.e., transactions operating on multiple shards), sharding blockchains must employ a cross-shard commit protocol to ensure transaction atomicity, significantly impacting system performance. A widely adopted [27; 28; 29; 30; 31] commit protocol is the two-phase commit [32] (2 PC), which requires three rounds of cross-shard communication under the critical path, causing high latency. Moreover, when committing a cross-shard transaction with 2 PC, the data record accessed by the transaction cannot be modified by others (e.g., via two-phase locking [33]), further reducing the throughput. Although Monoxide [34] eliminates this cross-shard coordination by using eventual atomicity, it restricts the types of transactions that can be processed, and the latency of cross-shard transactions is also higher than the 2 PC approach (detailed in Section 2.1).