## 4 Implementation of the BBSM Concept in the Virtual Environment
### Preliminary Experiment Results  
The experiment comprised 27 participants, all of whom were Master's degree students in mechanical engineering and were introduced to smart modes of manufacturing systems  
Figure 3: Flowchart of the player decision-making process. such as the SM concept. It should be noted that for such a complex game it is not trivial to make an intuitive and simple user interface that enables players to use the virtual world to its full extent. The developed user interface was functional for a group of up to 30 players. The web application was implemented using the MERN stack (MongoDB, ExpressJS, ReactJS, and NodeJS). The developed code of the online game is publicly available on the GitHub platform [58]. The game lasted for 90 minutes; the players were situated in different remote locations, and were permitted to communicate with each other. The game parameters defining the game dynamics were set as follows: \(f_{BC}=10\) s, \(d=0.87\), \(t_{initial}=300\) s, and \(t_{limit}=20\) s. The parameter values were selected to achieve congestion of the blockchain network in a reasonable game time. Due to the time limits of the experiment, the timeline was scaled down to ensure that events that would otherwise have happened over a longer period of time of days or weeks were captured during a shorter period in the experiment. The observed events, such as congestion of the blockchain network, are usually longer processes; therefore, the results acquired by this experiment are not affected by this kind of time scaling. Figure 4 shows the value of the transaction fee for confirmed transactions over the game time. The figure indicates that the value stabilizes after the first one-third of the play time. After half the play time (\(t_{1}\)), however, the transaction fee starts to rise sharply. An increase in transaction fees in a blockchain network indicates higher network occupancy, with users competing with each other to have their transactions be confirmed by increasing the transaction fee is collected by the block validator [59]. Towards the end of the game, it becomes clear that this increase has stopped. This may have happened because the players knew the approximate time of the game and were expecting it to end. For this reason, this last part of the experiment was not used in the subsequent analyses. Figure 5 shows the moving average (window size = 20 samples) of the price for a service provided for each type of service. The price of a service increases in the first half of the game, then (after \(t_{1}\)) the trend reverses and the price starts to fall below the values that were set at the beginning of the game. At time \(t_{2}\), the price for a service is equal to the transaction fee; after that time, the price for a service is lower than the cost of transaction confirmation by the blockchain network. The price of supply in free-market systems is affected by the supply-demand ratio [60]; in this case, it can be concluded that in the middle of the game the supply began to increase sharply. In connection with the dynamics of the transaction fee, this confirms that there was congestion in the blockchain network and that the frequency of service provision outpaced the frequency of transaction confirmation. Figure 4: Transaction fee of confirmed transactions over time. Figure 6 confirms the previous finding, showing that the number of services offered on the market first decreased; then, after the frequency of service provision outpaced the frequency of transactions, the validation began to increase. In addition, Figure 6 shows that the supply on the market fluctuated in waves during the first half of the game. This is because the players started the game on equal terms and at the same time. The same start time for all services resulted in near-synchronized provision of services. During the second half of the game, this fluctuation is not as obvious.