Abstract
Hyperledger Fabric (shortened to Fabric) is an open-source, enterprise-level, permissioned distributed ledger technology platform with a highly modular, configurable architecture. It supports writing smart contracts in general-purpose programing languages and has become the preferred choice for enterprise-level blockchain applications. However, the transaction throughput of the Fabric system remains a critical factor that restricts the further application of this technology in various fields. Therefore, it is necessary to evaluate and optimize the performance of the Fabric blockchain platform. Existing performance modeling methods need to be improved in terms of compatibility and effectiveness. To address this, we propose a performance-compatible modeling method for Fabric using queuing theory, which considers the limited transaction pool and the situation where node groups are attacked. Using the Fabric 2.0 version as an example, we have established a model of the transaction process in the Fabric network. By analyzing the model’s continuous 3D time Markov process, we solved the system stationary equation and obtained analytical expressions for performance indicators such as system throughput, system steady-state queue length, and system average response time. We conducted extensive analyses and simulations to verify the models’ and formulations’ accuracy and validity. We believe this approach can be extended to various scenarios in other blockchain systems.
1. Introduction
Hyperledger Fabric (shortened to Fabric) is a consortium blockchain platform that utilizes the smart contract paradigm and provides fully operable functionality. Due to its distributed nature and limitations in data processing, evaluating and optimizing the performance of various blockchains, including Fabric, has become a hot topic in academia [1–5]. With the rapid development and practical application of Fabric, there is a need for in-depth planning and deployment of network configurations. Developers need to know in advance whether the blockchain network’s throughput and latency can meet their requirements [6]. Additionally, different versions and configurations of Fabric may impact the performance in terms of throughput, transaction rejection probability, average transaction response time, etc.
Many studies have used experimental and formal methods to evaluate the performance of Fabric with various versions [7, 8]. However, to our knowledge, no formal method considering comprehensive parameters has been proposed for Fabric 2.0 [9]. The Fabric 2.0 framework’s different network parameters, such as peers, orders, organizations, block size, the number of finite transaction pools, as well as the state of the peer node group, should be considered to support the estimation of the system’s throughput and transaction latency.
To address this gap, we proposed a theoretical performance evaluation model for Fabric 2.0 based on queuing theory, which has been accepted by BSEW of EASE 2022 [10]. The proposed model considers the limited transaction pool and constructs a 2D Markov process. However, it does not consider the scenario where the blockchain peer node group is under attack or when too many malicious nodes stop working. The state of the peer node group is also a critical factor that impacts the blockchain system’s performance. Regardless of the consensus mechanism adopted by the peer node group, there will be a state where the node group is working correctly and a state where it stops working. Therefore, it is crucial to abstract this factor and integrate it into the performance model.
Building on the conference version paper, this paper extends and improves the proposed model by considering the operational status of the peer node group. The contributions of this paper are as follows:(1)We establish a queuing theory system for the Fabric 2.0 transaction consensus process.(2)We consider that the service process of transactions consists of two parts: block generation and consensus verification. We establish a queuing theory model that takes into account limited transaction pools and peer node group states. By analyzing the model’s 3D continuous-time Markov process, constructing a subrate matrix, and solving the steady-state probability vector of the system’s stationary equations. We obtain a finite series expression for performance metrics such as system rejection probability, system throughput, system queue length, and system execution time.(3)We simulate and test the queuing theory model using the MATLAB R2016a software platform. We adjust parameters such as transaction pool capacity, transaction arrival rate, and block size to simulate the impact of system parameters on performance metrics. The results demonstrate that our proposed model is stable and accurate. We conducted error analysis on test data and theoretical data of throughput and transaction response time, verifying the model’s applicability and effectiveness.
2. Background and Related Work
2.1. Hyperledger Fabric
Hyperledger Fabric (https://github.com/hyperledger/fabric) is an open-source permissioned blockchain platform that offers modular components, including membership services, chain codes, and subscription services. Figure 1 illustrates the three-phase transaction process for a Fabric 2.0 application attempting to update the ledger.
Proposal phase. In this phase, the application generates a transaction proposal and sends it to the designated node for endorsement. Each node participating in the endorsement will simulate the transaction by executing the chain code and respond to the transaction proposal by sending it back to the application.
Ordering and blocking phase. After completing the proposal phase, the application receives an endorsement proposal response from a specific set of nodes. At this stage, the application submits the endorsed transaction proposal response and the transaction itself to the order node. The ordering service creates transaction blocks based on the relevant configuration of the transaction proposal and distributes them to all peer nodes on the channel to proceed to the next stage.
Verification and submission phase. In this phase, after the peer node receives the transaction block from the order node directly or indirectly through gossip, it independently but consistently verifies each transaction in the block and updates the ledger.
For permissionless distributed blockchains like Ethereum and Bitcoin, any node can participate in consensus but is vulnerable to ledger forks. This means that different participants in the network may have different views on the order of transactions. Fabric’s order node provides ordering services for transactions and solves these problems. Additionally, Fabric’s design relies on a deterministic consensus algorithm, ensuring that blocks verified by peer nodes are final and correct. Several different implementations can achieve strict transaction ordering among order nodes, such as Solo, Kafka, and Raft. However, the Solo ordering service implementation is for testing only and contains only a single order node, so it has been deprecated. While the Raft allows different organizations to contribute nodes to a distributed ordering service, its ordering service is easier to set up and manage than a Kafka-based ordering service. Moreover, the Raft network is compatible with Solo users migrating to a single node. Therefore, Fabric 2.0 uses Raft as the consensus algorithm.
In the Raft consensus algorithm, a group of peer nodes implements the consensus process of transactions by electing a leader to manage the replication log. The application client submits the transaction proposal containing the endorsement to the order node, which receives transactions from different application clients simultaneously. Each ordering node automatically routes received transactions to the current leader of the channel. These transactions are packaged into blocks in a defined order, stored in the ledger of the order node, and ready to be distributed to all peer nodes that have joined the channel. Thereafter, each peer node independently verifies the received block of transactions in a deterministic manner to ensure that the ledger remains consistent. Specifically, each peer node in the channel verifies each transaction in the block independently to ensure that the node recognizes the required organization. This involves verifying that the node recognition and recognition strategy match and that the transaction does not invalidate other running transactions. Invalid transactions remain in the blocks created by the ordering node, but the node marks them as invalid and does not update the ledger’s state. When all peer nodes complete verification, the block is added to the chain. Figure 2 shows this consensus process.
2.2. Related Work of Performance Evaluation in Fabric
Many studies have employed experimental evaluation methods to assess the performance of different versions of Fabric, including Fabric v0.6 [3], v1.0 [2], v1.1 [11], v1.2.1 [12], v1.4 [13], and others. In a recent study, Dreyer et al. [9] examined the effect of indicators on the performance of Fabric 2.0 using testing methods and discovered that Fabric 2.0 outperforms the previous version in nearly all performance aspects.
In the domain of blockchain, modeling is another effective method for performance evaluation besides experiments [1]. Queuing theory is commonly used to model the performance of different blockchains, such as Bitcoin [14, 15] and Fabric [16]. Geyer et al. [17] introduced a queuing theory model to the Fabric platform and modeled the Solo sorting process as a queuing system. This model effectively captured the characteristics of the sorting phase in the solo implementation, but it is not applicable to the Raft or Kafka implementation of the later versions of Fabric. Jiang et al. [8] developed a hierarchical model for the Fabric v1.4.3 platform and applied queuing theory to analyze the impact of transaction arrival rate and endorsement timeout rate on the performance parameters of the Fabric transaction process.
However, the current models proposed for Fabric have limitations in terms of scalability. They do not consider a more detailed transaction processing process, nor do they investigate the relevant models of transaction pool limitations and node groups being attacked. Additionally, there is no existing research that provides an analytical solution for modeling the performance of various versions of Fabric, including 2.0. To address this challenge, our research builds an analytical model using queuing theory, which enables better performance analysis of Fabric 2.0.
3. Performance Modeling
Queuing theory is a mathematical method used to solve the performance and service quality of different types of queuing systems. In 1953, Daigle [18] proposed a classification method for queuing theory models. The representation of all classification types is described by three factors, namely X/Y/Z. Here, X represents the distribution of consecutive customer arrival time intervals during the input process, Y represents the service time distribution, and Z represents the number of service desks. In the 1971 Queue Theory Notation Standardization Conference, the above representation was extended to the form X/Y/Z/A/B/C. The meaning of the first three items remains the same, while the last three items are as follows: A represents the system capacity limit, B represents the number of customer sources, and C represents service rules such as first come first served (FCFS), last come first served, and random service.
The queues in computer communication networks and blockchain network systems are often arbitrarily complex and require the help of queuing theory to be solved. The main focus of this paper is to establish a related queuing theory model that analyzes the transaction process of Fabric 2.0 and provides a system performance evaluation.
3.1. Models and Parameters
Figure 3 illustrates the transaction consensus process of Fabric 2.0. When transactions are received by any order node, they are routed to the leader node’s transaction pool and queued. The transactions are then packaged to generate blocks based on the set block generation time and size. These blocks are distributed to peer groups for the execution of smart contracts and transaction verification. Once all peers have verified the blocks, they are sent to the blockchain network.
Here, we provide two distribution functions used in this paper and all parameters and their respective meanings in Table 1.
Exponential distribution [18]. The probability density function of a random variable X that follows an exponential distribution with parameter λ is given by the following:
The mathematical expectation (or expected value) of a random variable X is given by the following:
This means, that on average, the time between two consecutive events in a Poisson process is equal to 1/λ. For example, if λ = 2, then the expected time between two events is 1/2 units of time.
Generalized Erlang distribution [19]. Consider a two-stage process where services in stage 1 are exponentially distributed with parameter and services in stage 2 are exponentially distributed with parameter . Use to represent the time of each stage, and Y to represent the time sum of the two stages, that is, . Then the distribution function of Y is the convolution of and , that is, Y obeys the two-stage generalized Erlang distribution, and its probability density is as follows:
The mathematical expectation of a random variable Y is given by the following:
4. Queuing System
We built a queuing system for the process of Fabric 2.0.
4.1. Introduction of the Queuing System
Arrival process. Clients randomly send endorsed transactions to the ordering node for queuing. Since the randomly sent transaction flow has no aftereffect (i.e., the number of transaction arrivals in nonoverlapping time intervals is independent) and stability, we assume that the transaction arrival follows a Poisson process. That is the interval between the arrival of two adjacent transactions follows the exponential distribution with parameter λ.
Service process. The transaction service is divided into two separate phases. The first stage is block generation, where transactions arrive at the orderer group and are queued for the leader to package them into blocks. The block generation time follows an exponential distribution with a parameter of . The second stage is transaction validation, where the leader sends the packaged block to the peer node group to verify the transactions. The transaction validation time follows an exponential distribution with a parameter of . So the transaction service time follows the generalized Erlang distribution, and the average service time is .
Block generation rules. Transaction arrivals follow the FCFS principle.
The peer node group is attacked. We assume that the working status of the peer node group is divided into two types: normal service status (1) and out-of-service status when attacked (0). The failure time and repair time of the peer node group follow the exponential distribution with parameters and , respectively. The average failure time and average repair time are and , respectively.
The maximum system capacity. The queuing system can hold at most transactions. When no block is generated, the transaction pool can receive at most transactions. When the system performs consensus verification on a block, there are at most transactions in the queue.
Independence. We assume that all the random variables defined above are independent of each other.
4.2. A Continuous-Time Markov Process of Queuing System
In the queuing system, the order node group and the peer node group are considered two programs of a service station. The transaction service time follows the second-order generalized Erlang distribution. When the peer node group is under attack, the transaction is packaged to generate a block but not verified. Assuming that transactions arrive in the form of a Poisson process and the transaction pool accommodates a limited number of transactions, we establish a 3D continuous-time Markov process and obtain the system steady-state probability vector and performance metrics through matrix analysis.
Let represent the number of transactions in the queue, in the block, and the service status of the peer node group (0 is attacked state, 1 is normal service state) at time . Then, ( can be regarded as the state of the queuing system at time , where . Specifically, and denote that when no block is generated in the system, the number of transactions that can be accommodated in the queue can reach . Similarly, and indicate that when the last block is generated, the number of cross-chain transactions that can be accumulated in the queue can reach . Thus, for each case of ( in the system, we can write the following set :
Obviously, the random process ( is a 3D continuous-time Markov process with the state space . Figure 4 depicts the state transition relationship of {(.
Based on the state transition diagram, , represent the probability of state . Using this probability, we can derive all the state difference equations for this system.
For instance, from the state relationship in Figure 5 with state , we can derive the following state difference equations: transitions to with a transaction arrival rate of transitions to with a system repair rate of transition to with a transaction consensus validation rate of . Moreover, transitions to with a transaction arrival rate of transitions to with a system failure rate of ; and transitions to with a block generation rate of . Thus, the stationary equation for state is as follows:
Then, the state difference equations for all states are as follows:(i)State (ii)State (iii)State (iv)State (v)State (vi)State (vii)State (viii)State (ix)State (x)State (xi)State (xii)State (xiii)State (xiv)State (xv)State (xvi)State (xvii)State (xviii)State
Our objective is to solve the different equations presented above. However, solving thousands of differential equations can be a daunting task. Therefore, we need to identify a class of algorithms that can converge faster, thereby enabling us to solve them efficiently.
4.3. Algorithm Design
This section aims to utilize matrix geometry methods to solve the differential equations. However, due to the lack of symmetry in the equations, it is not possible to construct a minimum generator matrix with blocking characteristics. Therefore, we need to apply certain transformations to these equations.
Initially, we focus on the state equations . This series of states indicates that the consensus verification in the system has ceased, and transactions will continue to accumulate until the queuing system reaches its maximum capacity .
For Equations (19) and (20), let , we have the following:
That is
If
We have
Let
Then
Similarly, let , we get the system of the equation as follows:
When
Let
Then
That is
We can combine Equations (21) and (22) as follows:
When
Then
Let
Then
That is
Taking Equations (33–35) and (45) into (15–18), we get the following:
By combining Equations (7–14), (19–24), and (46–49), we can form a system of modified equations. This system can be used to obtain a minimum generator matrix.where are -order square matrix, and
Let be the steady-state probability vector of matrix Q, and each subvector is a -dimension row vector. Then, the modified steady-state equations can be expressed as follows:where is a column vector of appropriate dimension, then we have the following:
Since the matrix is a diagonal matrix, according to the matrix analysis method to solve the steady-state probability vector in the study of Elhafsi and Molle [20], we express the diagonal matrix as I (I is a square identity matrix of -order). Let , then
According to Equation (64),
Here, is called the subrate matrix.
Taking Equations (67) into (63), we get the following:
Where
Taking Equation (68) into Equation (62), we get the following:
Where
According to Equation (64), we get the following:
Then
The solving process of are shown in Algorithm 1.
| ||||||||||||||||||||||
For solve , we combine Equations (61) and (65)
Substitute the solved into Equations (66–72), we obtain the steady-state probability vector .
5. Performance Analysis
In order to ensure the stability of the queuing system, we have:
Based on the steady-state probability of this system, we present the finite series forms of several main indicators that reflect the performance of the queuing system, as follows:(1)Average queue length in queuing system(2)Transaction rejection probability in queuing system(3)Average transaction execution time in queuing system
The proof process is analogous to the literature [15], where is an integer function.(4)Average transaction response time in queuing system(5)Throughput in queuing system(6)Availability in queuing system
System availability is defined as the probability that a group of peers is functioning correctly. In the event of an attack on the peer node group, the system may become unavailable, resulting in an accumulation of transactions in the queue.
To obtain the trends of performance indicators in relation to any relevant parameter, we can refer to Equations (76–81). However, numerical calculations require us to simulate the model results by setting the parameter variation range based on the system architecture’s configuration.
6. Model Simulation and Validation
In this section, we will vary several critical parameters, such as transaction arrival rate, queuing system capacity, and block generation rate, to simulate the performance indicators of the Fabric 2.0 system.
6.1. Simulation Experiment Setup
To analyze the influence of system parameters on the above performance indicators of the system, we used the MATLAB R2016a software platform to simulate the impact of varying parameter values on the performance indicators. By setting different parameter values and running simulations, we verified the accuracy of our model and analyzed the system’s sensitivity to different parameters.
6.2. Performance Evaluation
(1)Influence of transaction arrival rate
In this section, we set , the capacity of the queuing system , and the failure rate and the repair rate of the peer node group are , respectively. When the range of is set to 200–4,000 , Figure 6(a)–6(f) shows changes in performance indicators such as the rejection probability of the system, and the average transaction response time in different block size , and different .
(a)
(b)
(c)
(d)
(e)
(f)
From Figure 6(a)–6(f), we can observe that the performance indicators are significantly impacted by the transaction arrival rate λ. However, the throughput is not affected by the block size, which is proportional to the transaction arrival rate. When the block size is large, the transaction arrival rate decreases, and the average transaction execution time becomes unstable. This is because the system generates blocks irregularly due to the small number of transactions arriving. When the block size is increased, the queue length, average transaction response time, and transaction arrival rate are proportional and inversely proportional, respectively. However, when the block is larger, and the transaction arrival rate is larger, the rejection probability is correspondingly large, and the system availability becomes small. In view of the mutual restraint and constraints of several performance indicators, blindly following large blocks and high transaction arrivals will not have good performance.(2)Influence of queuing system capacity ()
To explore the effect of system capacity on system performance, we set the variation range of from 100 to 4,000 . At this time, if the transaction arrival rate is set too small, the performance indicators will be unstable, so we set , and and . Figure 7(a)–7(f) shows the trend of change with each performance indicator.
(a)
(b)
(c)
(d)
(e)
(f)
Figure 7(a)–7(f) illustrates that the system is in an unstable state when the system capacity N is less than 600. At this time, the images of various performance indicators of the system experience severe shaking. The main reason is that the system capacity is too small, and excessive instantaneous trading can lead to system collapse. When the capacity of the system is above 600 , the system gradually stabilizes. As N increases, the queue length and response time increase proportionally, and the larger the block, the greater the effect and growth rate. But when the block is small, such as , the large capacity of the system will cause the model to fail. Mainly because the block size is set too small, the system load increases, and the model fails. Therefore, an appropriate block size (such as 30–50 ) can ensure the optimal performance of the system.(3)Influence of transaction consensus rate () or transaction generating rate (
The parameters and represent the consensus rate for blocks and the block generation rate, respectively. Their values are related to the performance of ordering nodes and peer nodes. We assume that the ranges of and are both 0–100 . When and , and take values of 100. Figure 8(a)–8(f) shows the variation of the performance metrics with respect to at different block sizes.
(a)
(b)
(c)
(d)
(e)
(f)
From Figure 8(a)–8(f), it can be seen that the change of has little effect on the length of the queue, the response time to the transaction, and the system throughput. However, with the increase of , the rejection probability first decreases and then tends to 0, the execution time decreases accordingly, and the system availability gradually increases and tends to be stable. This is because the higher the efficiency of the transaction block, the higher the probability of receiving the transaction, the lower the probability of rejection, and the shorter the transaction execution time. When is fixed, changes in block size have very little effect on throughput and execution time. As block size increases, the queue length and response time decrease accordingly, so large blocks are the best option in the current state. Since each performance indicator has a similar trend of change to , it will not be described in detail here.(4)Influence of peer node group failure rate () or repair rate
The parameters represent the failure rate and repair rate of the peer node group, respectively. Their values are related to the severity of damage to the node group under attack and the speed of the repair process. The range of values for is 20–400 , which allows us to calculate the average failure time and repair time for the system’s current state. Assuming , and fixing and to 40 , Figure 9(a)–9(f) shows the trend of performance indicators under different block size settings.
(a)
(b)
(c)
(d)
(e)
(f)
From Figure 9(a)–9(f), it can be seen that the change of has little effect on the system throughput and transaction rejection probability. As increases, the mean time to failure of the peer node group decreases, resulting in a decrease in queue length, transaction execution time, and transaction response time. The system availability also tends to be stable. These changes can be explained by the increase in transaction execution speed. When the block size is set to , the system may become unstable, indicating that the block size should not be too small.
The impact of on performance indicators is similar to and does not require repetition here.
Since different parameters have an independent relationship, it is appropriate to study the impact of each parameter on the system’s performance indicators. The figures provided in the previous section can also be used to conduct sensitivity analysis of different parameters on performance metrics. For example, the study shows that the system’s throughput is sensitive to the transaction arrival rate (), and the transactions throughput (TPS) and are consistent over time.
The queue length of the system () is sensitive to parameters such as transaction arrival rate (), network size (N), consensus rate (), and failure rate (), especially when network size (N) increases. To ensure normal system operation, the block size setting (b) needs to be continuously increased. The execution time of the transaction () is less affected by N, and other parameters, such as transaction pool capacity (N), have less impact on performance. The block size (b) can only play a role in combination with and other parameters. There is a relationship between several performance indicators and influencing parameters, so setting an appropriate block size is crucial to optimize the performance of Fabric and meet the system’s performance requirements.
Our study highlights the critical role of transaction pool capacity (N) and node group working status () on the performance of the system cannot be overstated, in contrast to previous studies that have overlooked their importance. Therefore, it is crucial to set optimal values for N and to enhance the efficiency of transaction processing and ensure the security of the system.
6.3. Model Experimental Verification
To validate the accuracy of our proposed model, we deployed a Fabric 2.0 network on a high-performance server with 48C 187G specifications, using the Raft ordering service to establish an ordering node and a validator group node that comprises three peers. We utilized Hyperledger Caliper (https://github.com/hyperledger/caliper), a benchmarking tool, to evaluate the performance of various blockchain solutions under custom use cases. The system’s capacity was set to and the transaction arrival rate () was vary from 500 to 3,000 . We also assumed that the node group verification would halt for 50 ms, followed by a 40 ms restart, resulting in and . We conducted tests to measure the average transaction response time and system throughput and compared the results with the theoretical values.
As depicted in Figures 10 and 11, a comparison between the theoretical and test values of the system’s throughput and cumulative probability was conducted. It is evident that the system’s throughput test value dwindled to 1.41 (txs) when the transaction arrival rate reached 2,200 (tx/s), owing to a node cluster failure that halted the system’s operation. Nonetheless, disregarding the test value’s outlier, the theoretical throughput value aligns almost perfectly with the test value. Furthermore, the maximum throughput error does not exceed 162 (txs), which is negligible in comparison to the vast range of throughput levels. These results suggest that the throughput equation of the queuing system is highly effective.
As depicted in Figures 12 and 13, a comparison between the theoretical and test values of transaction response time and cumulative probability was conducted. Our findings indicate that when the transaction arrival rate exceeds 600 (tx/s), the test value of the transaction response time is lower than the theoretical value. This phenomenon can be attributed to the limited number of peer nodes, resulting in an actual verification rate for block consensus that surpasses the theoretical verification rate, thereby leading to a slightly better test value effect. Nonetheless, the maximum error between the theoretical and test values of response time is 12.28 (ms), and the average error is 8.09 (ms), highlighting the need for repeated experiments to mitigate the error difference.
7. Discussion and Conclusion
In this study, we present a viable and scalable modeling approach based on Fabric 2.0. Our methodology involves the development of a queuing theory model that accounts for both the finite transaction pool and the fault state of node groups. We utilized the geometric matrix method and subrate matrix method to derive the solution of the difference equation and obtain crucial performance indicators related to the queuing system model, including the system queue length, system rejection probability, transaction delay time, and response time. Subsequently, we conducted a series of experiments to validate the simulation model by simulating the system’s performance through a parameter change process simulation and verifying the model’s effectiveness. Finally, we assessed the applicability of the proposed model by benchmarking experimental data against theoretical data.
The modeling approach proposed in this study can be extended to other blockchain systems with similar processes. As an example, we applied the approach to a typical blockchain cross-chain technology, Cosmos, to assess the model’s applicability. The research outcomes have been published in the renowned international conference ICPADS 2022 [21].
The work presented in this paper has several limitations. First, our modeling approach is limited to detecting performance indicators such as maximum throughput and minimum transaction delay under current settings, such as a predetermined consensus mechanism and a fixed number of nodes. While adjusting system parameters under the current transaction arrival rate and block size settings can provide optimal system states, these parameters’ optimal values cannot surpass the blockchain architecture’s rigid constraints. Second, the performance metrics obtained from our model are probabilistic average values. In the case of abnormal conditions, such as system failure caused by a large influx of transactions or outlier events induced by consensus mechanism attacks, identifying their underlying causes may be challenging.
Therefore, future research directions should focus on two aspects. First, it is necessary to supplement other relevant variables and conduct performance analysis on blockchain systems to optimize the existing queuing theory models. Second, the research should aim to develop an error analysis for the consequences of outliers.
Data Availability
No underlying data were collected or produced in this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work is jointly supported by the National Key Research and Development Program of China (no. 2019YFE0105500) and the Research Council of Norway (no. 309494), as well as the National Science Foundation of Zhejiang Province (no. LY22F020021), the Key Research and Development Program of Jiangsu Province (no. BE2021002), and the Innovation Project of State Key Laboratory for Novel Software Technology (Nanjing University) (no. ZZKT2022A25).