# Decentralized Public Transport Management System Based on Blockchain Technology +
## 3 System Design and Implementation
### Proposed System Description
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Architectural Layer** & **Components** & **Functionality** \\ \hline \multirow{4}{*}{Smart Contract Layer} & ERC-721 token contract & Vehicle token management \\  & State management contract & Value modification handling \\  & Maintenance trigger contract & Automated maintenance scheduling \\  & Access control contract & Permission management \\ \hline \multirow{4}{*}{Consensus and Validation Layer} & PoA consensus mechanism & 25 TPS throughput optimization \\  & Transaction validation & Private network operation \\  & Node configuration & Token value validation \\  & Real-time updates & System performance monitoring \\ \hline \multirow{4}{*}{Data Management Layer} & Maintenance history storage & Immutable record keeping \\  & Token value transactions & Value modification tracking \\ \cline{1-1}  & IoT data integration & Sensor data processing \\ \cline{1-1}  & Event logging & Maintenance event recording \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Blockchain integration architecture components. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Characteristic** & **Value** & **Background** \\ \hline \multirow{4}{*}{Network capacity} & \multirow{4}{*}{Twenty-Five Transactions Per Second (TPS)} & The number of buses in 1 city with a population of up to 1 million is up to 1500 units. It is necessary to receive the status of transactions and technical conditions at least once every 60 s. This means that the network bandwidth is sufficient at the level of 25 TPS. \\ \cline{1-1}  & 1500 tokens & We divide each token into 500 thousand parts. \\ \hline Type of tokens & Stablecoins & Each token is provided with 1 real vehicle \\ \hline \multirow{2}{*}{Token Standard} & ERC-721 & Each asset (vehicle) is unique and not interchangeable. There is no task to exchange with other tokens since the solution works completely in a private blockchain. \\ \hline Issue of tokens & Possible & When expanding the participants using the proposed system. \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Main blockchain characteristics. Further, each of the subsets of messages \(S_{1}\),... \(S_{B}\) is compressed by the compression operator \(A_{z}\): \(A_{z(S_{1})}\),... \(A_{z(S_{B})}\), thus, the solution would be considered better if B is minimal. The minimum B is further denoted as OPT. _V--the volume of the container in bytes; \(n\)--the number of messages from sensors in the buffer; \(A_{i}\)--the volume of the \(i\)-th message in bytes; \(B\)--number of containers; \(Y_{i}\)--equals \(1\) if container \(i\) is used or 0 otherwise; \(X_{\{i,j\}}\)--equals \(1\) if message \(j\) is placed in container \(I\); \(A_{z}\)--is an operator for compressing messages placed in a container. The task is to minimize \(B=\sum_{(i=1)}^{n}Y_{i}\) under the set constraints. The total size of messages placed in the container and then compressed by the compression operator cannot exceed the size of the container:_  
\[A_{z}:\left(\sum\limits_{n,i=1}^{n,j=1}a_{j}X_{i,j}\right)\leq VY_{i},i\in\{1,\ldots,n\} \tag{3}\]  
_All \(n\) messages must be placed in containers as follows:_  
\[A_{z}:\left(\sum\limits_{n,i=1}^{n,j=1}X_{i,j}\right)=1,\forall_{j}\in\{1, \ldots,n\} \tag{4}\]  
_where \(Y_{i}\in\{0,1\},\forall_{i}\in\{1,\ldots,n\},X_{i,j}\in\{1,\ldots,n\},\forall _{j}\in\{1,\ldots,n\}\), where \(Y_{i}=1\) and if container \(i\) is used and \(X_{i,j}\) if the message is placed in container \(i\)._