# NeuChain+: A Sharding Permissioned Blockchain System with Ordering-Free Consensus
## 2 Background and Motivation
### OEV Architecture  
As shown in Figure 2a, most blockchain systems [26; 27; 28; 29; 30; 34; 35; 36; 37; 38; 39] adopt the OEV architecture, which operates in three steps:  
1. After receiving transactions from clients, the consensus leader batches these transactions into a block and determines the execution order of these transactions so that each node can obtain the same results. The consensus leader also pre-executes these transactions to ensure their validity. 2. The block is then replicated to other follower nodes. Since block execution is performed locally, a node must execute the block based on the given order to update its local ledger. Otherwise, if two nodes execute these transactions in a different order, their local ledger copies will be inconsistent. 3. Meanwhile, the node validates the block and its contained transactions to prevent faulty behaviors by the leader node. Figure 2: (**a**) Order–execute–validate architecture; (**b**) execute–order–validate architecture; (**c**) order–execute–parallel–validate architecture; (**d**) execute–validate architecture; (**e**) sharding–execute–validate architecture. Transaction execution in the OEV architecture is performed serially to ensure deterministic results, which could be a performance bottleneck. Blockchains represented by Elastico [26] adopt the sharding technique to solve this bottleneck, allowing parallel transaction execution among shards. However, Elastico does not support cross-shard transactions and state sharding, meaning every node maintains a full copy of the ledger. Other OEV sharding blockchains [27; 28; 29; 30; 34; 37; 38; 39] adopt state sharding to solve the above issues. They divide the ledger into shards and use commit protocols represented by 2 PC to ensure the atomicity of cross-shard transactions, as shown in Table 1.  
2 PC is widely used as the cross-shard commit protocol, and several variants of 2 PC exist [30]. For example, in shard-driven 2 PC, cross-shard transaction \(T\) involves shard \(S_{1}\) and \(S_{2}\). Since \(T\) can only be committed if all shards commit \(T\), when \(S_{1}\) can commit \(T\), it sends the 2 PC request to \(S_{2}\). When receiving the request, \(S_{2}\) decides whether \(T\) can be committed and replies its vote back to \(S_{1}\). \(S_{1}\) commits \(T\) locally only when all shards can commit \(T\). Otherwise, it aborts \(T\). The decision is also notified to the other shards \(S_{2}\). However, this process requires three rounds of communication between shards, and before starting a round, the initializing shard must reach a consensus on its decision, resulting in significant communication overhead. Meanwhile, as the commit decision cannot be changed after achieving consensus, the corresponding data records cannot be modified by another transaction during 2 PC [33], significantly limiting the performance of transaction execution. For other protocols, Monoxide [34] proposes the eventual atomicity to handle cross-shard transactions. When transferring money between accounts, the transaction is guaranteed to be committed after the source account is debited, as adding money to the target account must not violate consistency. Therefore, 2 PC is not needed for such types of transactions. However, since faulty shard leaders may refuse to accept these \"relay\" transactions, cross-shard transactions may require several blocks to be committed, resulting in increased latency. To reduce this unlimited latency, BrokerChain [38] proposes a duration-limited eventual atomicity to ensure that the execution of cross-shard transactions is completed in a known upper bound. However, it is still only applicable to specific types of transactions. To handle complex smart contract transactions, Meepo [37] proposes cross-epoch and cross-call to execute cross-shard transactions. Regardless of how many shards the cross-shard transaction involves, it can be committed in a single round of consensus. However, its coordination rounds depend on how many shards are involved in the transaction.