## 4 Functional Modules of the Proposed System
### Service Inquiry Eroking Module  
We represent each matching process as a set of chaincodes, which are instantiated on the blockchain by the market's two-side users (i.e., SPs and SRs). The enrolled members published their services inquiries in SC (cf. Table 1). The types of services, denoted as servicetype, are divided into the following two kinds: request and provide.  
Figure 4: The transition diagram of the corresponding state machine of the service inquiry.  
Figure 3: The interaction with the CA in the user registration process.  
Each newly posted service inquiry, as mentioned above, has a fixed available time. Each service inquiry attempts to evoke the match function in the Service Chaincodes at a fixed period until it is matched. In our system, the \"Number of Available Invokes (NOAI)\" records the number of times each service inquiry does invoke the match function. Whenever a match function executes for a service inquiry, the number in NOAI is decreased by one. Let \"serviceClass\" denote the classes of service substances of a TimeBank.  
Figure 5 shows some service substances taken from TimeBanks USA and their supply-versus-demand ratios. It is worth mentioning that the number of offers may not be realistic. When someone wants to join the TimeBanks USA, they need to tell the system what services they can provide. When someone needs help, the TimeBanks USA's staff will use the phone to ask members to provide the service. Therefore, the number of members who can provide services must be less than the number of offers in the figure. For simplicity, we select the three most demanded services as the service substances in the proposed system, including HelpatHome, CommunityActivities, and Home.  
The service chain codes will classify these service inquiries in the blockchain according to the associated service states. In our system, each service inquiry becomes the matching candidate for another service if they have the same \"serviceClass\" and need to be within the same available time interval. We use \"serviceTime\" to record the time interval for  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Elements in the Service Chaincodes** & **Explanation** \\ \hline _ServiceType_ & The service can be provided or requested. \\ \hline _posterName_ & The user who posted the service on the blockchain. \\ \hline _serviceClass_ & Substances of the service. \\ \hline _serviceTime_ & The time interval for supplying or demanding services \\ \hline _postTime_ & A timestamp of the publishing the service. \\ \hline _state_ & Each service has five status in its life cycle. \\ \hline _serviceOwner_ & Other services matched up with the target service. \\ \hline _NOAI_ & Number of available invokes. \\ \hline \(v\) & A voting parameter depends on the situation \\  & of matching. \\ \hline \multirow{2}{*}{\(\alpha\)} & A “0 to 1” tuning parameter for reducing redundant \\  & waiting time. \\ \hline \hline \end{tabular}
\end{table}
Table 1: The parameters in the service proposal.  
Figure 5: Relative service ratios of supply-versus-demand measured in TimeBank USA.  
supplying or demanding services. The \"serviceTime\" in a service-post plays a critical role in justifying the service's qualifications to be a candidate.