## Dynamic Matching Strategies in Two-Sided Markets
### Dynamic Tuning Strategy  
As pre-described, our TimeBank is a community-based system. There are a limited number of market members; therefore, the system performance is susceptible to the market's quantity. For promoting the embrace of TimeBank, we should enlarge her node density (or number of active members) to an economic scale to provide attractive system performance. Therefore, in this paper, a market thickness-based dynamic matching strategy is presented for bettering our system performance. The basic idea is that \"increase the possible links per node does give each node more matching candidates.\" However, in a blockchain-based TimeBank, all of the matching strategies are realized on chaincodes. That means the on-ledger matching strategy does not have the flexibility to meet the dynamically changed market conditions. For example, if the market is very thick, but all nodes are programmed to follow the patient algorithm, it will cost a lot of time to find a match. Therefore, we need a more flexible (or dynamic changing) strategy to handle different real market situations. In some sense, a Dynamic Tuning Strategy (DTS) will also thicken the market to reduce system losses, just like the patient algorithm. But DTS does not need to postpone the match of a node until the node becomes critical. In this work, a system parameter decides whether the market prefers the patient algorithm or the greedy one that is defined to control the system's preference about the patient or greedy during the matching process. When the market is thin, all in-market nodes prefer to take a patient-oriented strategy. On the other hand, when the market is thick, all the nodes prefer not to wait too long to get a match. Since a blockchain-based system does not have a global planner, the matching process must be run by all users. When someone posts a service inquiry to the blockchain, the corresponding node will invoke the matching function, and this matching function should be DTS-based. Conceptually, the proposed DST mechanism is a mixture of the pre-described greedy and patient mechanisms, and this will be detailed in the next subsection. (1) Voting Mechanism: After a user posted their service proposal on the blockchain, the corresponding node queries match related data of the other inquiries on the blockchain. This work assumes that \(N_{i}\) is the set of neighbors to a service \(S_{i}\), where a neighbor to the service \(S_{i}\) means the matching condition of that node is compatible with that of the \(S_{i}\). Furthermore, we also denote the set of the voting states as \(V\) for each posted service inquiry, where the collection of voting states, \(V\), consists of the following two elements:  
* \(v_{p}\): the state of the service inquiry tends to be patient for the current market;
* \(v_{g}\): the state of the service inquiry tends to be greedy for the current market. Every time the user invokes a DTS-based matching, the service inquiry can flag itself with vote state \(v_{p}\) or \(v_{g}\) and write the chosen state into the set \(V\) in the service inquiry, as shown in Algorithm 1. Figure 10: System losses vs. the number of expected links per node, d, if the patient and the greedy matching strategies are adopted. ```
Result: Service matching decision \(D\) for\(i=1:m\)do  Querying Market Data: for\(j=1:K\)do  Compatible\(N\gets S_{j}\)  end for  Voting Mechanism: if\(N(s)=0\)then \(V_{sn}\gets V_{p}\) else \(V_{sn}\gets V_{g}\)  end for NOAI = (\(m-i\)) \(\alpha=\underset{m\text{(V}_{p})}{\text{(}num\text{(V}_{p})+num\text{(V}_{g}) \text{)}}\) \(TH=m-\lfloor m*\alpha\rfloor\)  Decision Function: ifNOAI<THthen  Match(\(S_{x},N\)) \(D=Match\) else \(D=Wait\)  end for
```  
**Algorithm 1**Dynamic Tuning Strategy  
If \(Si\) does not have any neighbors, it means \(S_{i}\) does not comply with other service inquiries' matching conditions in the current market. \(S_{i}\) cannot complete the match process at this time, so it prefers waiting for other nodes.