## 6 Experiment Result  
In this work, we simulate the whole process starting from users' stochastically arrivals to the blockchain, posting their service inquiries, and then waiting to find a match. Our experimental system and simulation are built and conducted on a personal computer with Intel 6700K CPU, 24 GB RAM, and Ubuntu 16.04. The Fabric version is 1.4 and all the nodes are running in Docker, where the version is 18.09.3. Our matching experiments consist of two parts. The first is an experiment of matching under the greedy and patient algorithms. The second is to simulate finding a match in the real market scenario under the greedy, the patient, and the DTS-based matching algorithms. The pre-described system losses are used to measure the corresponding performances. In our simulation:  
* The average arrival time interval is 5 s and follows a Poisson Process. * The total number of services is 250. * The matching period is 40 s.
* The available time is 200 s.  
Figure 12 presents the simulation results under the two static algorithms. The market will highly concentrate on the corresponding quantity ranges under both algorithms. In the greedy algorithm, the concentration range should be approximately (6, 15), while the patient algorithm's results should be close to (20, 40). Table 2 shows the system performances under the different three algorithms. The loss of the greedy algorithm is the largest, but the waiting time is the shortest. While the patient algorithm causes the smallest loss, however, it takes the longest waiting time to find a match. The loss obtained in the DTS-based matching algorithm is only slightly worse than that of the patient algorithm, but it dramatically reduces the waiting time. That is to say, if a DTS-based matching algorithm is used, users can save more than half of the waiting time, and the loss can be controlled to an acceptable range. More importantly, as for the average neighbors, the greedy algorithm gives only one neighbor to one node when it finds a match. In Figure 13, we use a DTS-based matching algorithm to simulate the matching scenario in the time banking system. Unlike previous simulations, no service will arrive at the market after a certain point in time. This simulation will show that when the service to the market changes drastically, the system's strategy will automatically tune the alpha and maximize the overall matching rate. \begin{table}
\begin{tabular}{c c c c} \hline  & **Loss** & **Waiting Cost** & **Average Neighbor** \\ \hline
**Greedy** & **0.328** & **0.12** & **1.184** \\ \hline
**Patient** & **0.264** & **0.86** & **3.864** \\ \hline
**DTS** & **0.283** & **0.36** & **3.12** \\ \hline \end{tabular}
\end{table} 
Table 2: The performance comparison among three different strategies. From the results of the simulation, we can divide it into the following three phases:  
1. When the system begins running, the market would be very tiny, so the hasty increment due to each service's vote caused the value of \(\alpha\) to change substantially. On the other hand, because the market size is small and the probability of matching is low, \(\alpha\) will be biased towards 1, and the timing strategy of the system tends to wait. 2. When the market gets thicker, \(\alpha\) will slowly be decreasing, and the corresponding value change will become smoother, representing services in the market that can get matched in shorter waiting times. 3. When the service's arrival is interrupted, \(\alpha\) will gradually increase, allowing the market to maintain its match rate based on the proposed waiting mechanism. From the simulation results, we observed that DTS could stabilize the market thickness of TimeBanks in the community-based mutual assistance systems and effectively provide a high matching rate. Compared to the static matching algorithms, DTS flexibly changes the timing strategy based on the number of nodes in the market and the number of links of each node. TimeBanks in different communities do have different arrival rates and matching rates.