# NeuChain+: A Sharding Permissioned Blockchain System with Ordering-Free Consensus
## 5 Cross-Shard Transaction Processing Protocol
### Transaction Conflict Detection
Therefore, this situation cannot be addressed by reordering, and \(T_{3}\) needs to be deterministically aborted to commit \(T_{1}\) and \(T_{2}\). ```
0: A complete reserve table containing accounts involved in cross-shard transactions, A set of transactions \(TS\) of epoch \(n\)
0: The commit set and abort set of transactions \(TS\) of epoch \(n\)
1:for\(T\in TS\)do
2:for\(w\in T\).\(WS\)do
3:if\(WT\) [\(w.key\)] < \(T.tid\)then
4: Abort \(T\) and continue;
5:for\(r\in T\).\(RS\)do
6:if\(WT\) [\(r.key\)] < \(T.tid\)then
7: Abort \(T\) and continue;
8: Commit \(T\);
```  
**Algorithm 3** Detect conflict. An example of the transaction of account amalgamating.It is convenient for readers to better understand the entire processing of cross-shard transactions. This is a detailed description of the transaction of account amalgamating as an example. In this example, there are two shards: Shard \(S_{0}\) containing accounts \(A\), \(B\), and \(C\), and Shard \(S_{1}\) containing accounts \(D\) and \(E\). As depicted in Figure 5, the transaction set to be sent by the client includes the transaction amalgamate(\(C\), \(D\)) and other intrashard transactions. Amalgamate(\(C\), \(D\)) is aimed at merging accounts \(C\) and \(D\). It comprises four operations, referred to subsequently as \(Op_{1-4}\), which are to obtain the balance of \(C\), obtain the balance of \(D\), update the balance of \(C\) to \(0\), and update the balance of \(D\) to the sum of the original balances of \(C\) and \(D\). The client divides the complete transaction set into two subtransaction sets and sends them to \(S_{0}\) and Shard \(S_{1}\), respectively. After the preparation phase, amalgamate(\(C\), \(D\)) is assigned to the Epoch \(N\) and is also assigned a unique \(tid\). During the execution phase, the intrashard block server executes this transaction deterministically. It is noteworthy that for cross-shard transactions like amalgamate(C, D), operations are executed based solely on the accounts contained within the local shard. Specifically, \(S_{0}\) executes only \(Op_{1}\) and \(Op_{3}\), while \(S_{1}\) executes only \(Op_{2}\) and \(Op_{4}\). However, since \(Op_{4}\) depends on the read set of \(Op_{1}\), it cannot be executed directly, but if \(Op_{1}\) has completed execution and sent the read set to \(S_{1}\), then it can directly read the prereceived read set from the local cache for executing (according to Algorithm 1). Otherwise, it is temporarily pended and continues to execute other transactions. After the deterministic execution is completed, _cross-reserve_ first generates the intrashard reserve table (according to Algorithm 2, Lines 5-13, the bold words in Figure 5). In this example, \(S_{0}\) reserves the update of \(C\) from amalgamate(\(C\), \(D\)), while \(S_{1}\) reserves the update of \(D\) from the other transaction. After merging reserve tables of _cross-reserve_ (according to Algorithm 2, Lines 14-25), the reserve tables in both shards have the same row of \(C\) and \(D\) (the gray words in Figure 5). \(S_{0}\) and \(S_{1}\) conduct conflict detection based on the complete reserve table (according to Algorithm 3). According to the deterministic rule, this transaction exists with a WAW dependency. As a result, amalgamate(\(C\), \(D\)) ultimately is aborted.