## 4 Correctness Argument
### Stability and Safety  
In this protocol, the Leader node broadcasts \(Tct\) messages (a total of \(\frac{n}{k}-1\) messages) in the shard. The client segment sends transaction information to each node in the shard (a total of \(\frac{n}{k}\) messages), and each node will broadcast a confirmation message (a total of \(\frac{n}{k}*[\frac{n}{k}-1]\) messages). The number of messages \(S\) required to complete transaction confirmation in a shard is shown in Equation (9). \[S=(\frac{n}{k}-1)^{2}+\frac{3n}{k}-2 \tag{9}\]According to the PBFT process, the client sends a request message to the Leader node, which broadcasts a pre-prepare message to each consensus node (total of \(\frac{n}{k}-1\) messages). Each node broadcasts a prepare message (total of \([\frac{n}{k}-1]^{2}\) messages) and a commit message (total of \(\frac{n}{k}*[\frac{n}{k}-1]\) messages). The number of messages required to achieve consensus in a shard with the same configuration is shown in Equation (10). \[S^{\prime}=2(\frac{n}{k}-1)^{2}+\frac{2n}{k}-1 \tag{10}\]  
The intra-shard consensus of the protocol requires only about half the number of messages required by PBFT to achieve consensus. Under the same computer and network conditions, the consensus of this protocol is less negatively affected by the increase of nodes than PBFT. This protocol has better stability and can also reduce the consumption of network resources and storage space. If multiple verifications of the system are due to mishandling of transactions by validator nodes or wrong transaction messages, the alliance chain will not return to normal until the malicious nodes are removed. Malicious verification nodes or wrong transactions can cause _Tct_ to affect stability. The existing protocols for selecting a Master node have certain characteristics. One approach involves selecting a different node as a Master node in each epoch or round according to the rotation rules, which introduces latency and additional communication overhead and allows an attacker to control the rotation order [7; 35]. Another approach is staking-based selections, which incentivize nodes to follow the rules and maintain normal behavior [47]. Over time this could lead to centralization within the system. Performance-based selection can improve system efficiency but can cause some nodes to become masters, continually reducing the utilization of others [34]. The protocol design utilizes locally generated verifiable and unpredictable random values for selections. This approach has several advantages, such as protection against attacks and falsification of lottery result, and maintaining low energy consumption and uniqueness of result. Regarding node assignment, methods based on node properties (such as liveness and performance) have centralization risks [22; 35], while free-choice assignment methods are less resistant to malicious behavior [28]. In the protocol design, the identification ID for node assignment calculation considers how nodes can manipulate their IP addresses using proxies or other methods. The node assignment is achieved through cryptographic calculations of various parameters, incorporating the public key and the epochRandomness involving the participation of multiple nodes. While not eliminating the possibility of manipulating individual parameters, this guarantees a robust and manipulation-resistant identity generation process. Consensus nodes are responsible for the duties of validating transactions and sending challenge messages. Both wrong verification and challenge failure will reduce the reputation of the consensus node. Leader node is responsible for adjusting the transaction confirmation threshold, counting the number of confirmation messages, and generating microblocks. If the Leader node sends different values of _Tct_ to each consensus node or does not send to some consensus nodes, the consensus node will replace the Leader node due to inconsistent status.