## 3 Dynamic Transaction Confirmation Sharding Protocol
### Network Infrastructure  
The protocol design incorporates three types of validator nodes: consensus, Leader, and Master nodes. Each subcommittee comprises all consensus nodes and Leader nodes in a single shard, and the only consensus committee comprises all Leader nodes and Master nodes. Consensus nodes validate transactions and submit the final consensus result to the Leader node within their respective subcommittee. The Leader node packages the transactions completed in consensus into microblock and submits microblock to the unique Master node for each epoch. The Master node organizes the validation of microblocks within the consensus committee and packages the validated microblocks for upload to the alliance chain. After the status of all validator nodes is synchronized, each Leader node will randomly generate a string. The Master node merges this set of strings, adds the latest block hash, and finally performs a secure hash algorithm(i.e., SHA256) calculation on the result to get epochRandomness. The Master node broadcasts the obtained epochRandomness to the whole network, and then the system executes the view replacement protocol to transition to the next epoch.  
At the beginning of the epoch, all nodes combine the (_IP_, _PK_) identity information group (representing their internet protocol address and public key respectively) and the epochRandomness sent by the system to calculate their identity _ID_. The calculation method is provided in Equation (2).  
\[ID=SHA256(IP+PK+epochRandomness) \tag{2}\]  
Each node in the system executes a modulo operation using its _ID_ and the total number of shards. The result of this modulo operation corresponds to the number of the committee to which the node belongs (in the range of [0, 1, 2,..., (total number of shards)-1]). In each subcommittee, the node with the smallest ID will become the Leader node. Each Leader node uses the private key (hereinafter referred to as SK) as input to execute VRF (verifiable random function), judges whether it is the Master node according to the output result, and broadcasts verifiable selection information contained in the result if it judges itself as the Master node. Node state transitions are depicted in Figure 1. Algorithm 1 describes the node assignment and selection algorithm step-by-step using pseudocode.  
It is crucial to record node information in the shard during the implementation process. This information is directly linked to subsequent node selection and message sending. Figure 2 shows the key codes.  
Figure 1: State transition of node. A node obtains an ID and determines its shard membership by performing a modulo operation. The node enters the shard and actively participates in the subsequent selection process for selecting the Leader node. If a node becomes a Leader node, it also participates in the selection process for selecting the Master node.  
Figure 2: The C++ codes for retrieving the shard and other node information after the node enters the shard. Subsequent node communication relies on this information.  
```
1:\(IP\), \(PK\), \(SK\)
2:\(Node\_ID\), \(Node\_shard\), \(Node\_state\)
3:\(k\) = total number of shards
4:\(Shard\_number\in[0,k-1]\)
5:Identity computing:
6:Node receives the \(epoch\_Randomness\) broadcast
7:\(Node\_ID=SHA256(IP+PK+epoch\_Randomness)\)
8:Node assignment:
9:\(Node\_shard=Node\_ID\ mod\ k\)
10:Node selection:
11:if\(Node\_ID\) is the smallest in the shard then
12:\(result=VRF(SK)\)
13:if\(result=yes\)then
14:\(Node\_state\) = Master node
15: broadcast \(result\)
16:else
17:\(Node\_state\) = Leader node
18:endif
19:else
20:\(Node\_state\) = consensus node
21:endif
22:return\(Node\_ID\), \(Node\_shard\), \(Node\_state\)
```  
**Algorithm 1** Node assignment and selection