\chapter{Conclusion}
\label{chap:conclusion}

\section{Summary of the Thesis}
\label{sec:conclusion_summary}

This thesis project started with a clear and serious problem. As we discussed in our Introduction in Chapter 1, the railway industry is a safety-critical part of our economy. It depends on managing a huge inventory of complex assets. The traditional systems used for this asset management are often old, centralized, and not connected to each other. This creates ``data silos,`` where different stakeholders (like operators, maintenance crews, and part suppliers) cannot share information. This leads to a fundamental lack of trust, transparency, and data integrity. These problems are not just about inefficiency; they create serious risks for safety and cost the industry a lot of money.

Our goal was to design and build a modern system to solve this. We wanted to create a single, shared, and trusted source of truth for all asset data and maintenance records.

To understand how to build this, we first did a deep review of the academic literature in Chapter 2. This review showed two main things. First, we confirmed that the problems in the railway industry are real and well-known, and many researchers are trying to find better, data-driven solutions. Second, we saw that blockchain technology is a very powerful tool for creating trust, transparency, and immutability, and it is used in many other industries (like food, pharma, and shipping) for asset tracking.

However, our literature review found three major ``gaps`` in the existing research for the railway industry:
\begin{enumerate}
    \item \textbf{A Gap Between Theory and Practice:} Most of the existing papers are only ``conceptual frameworks``. They propose high-level models but do not show a full, working, end-to-end implementation.
    \item \textbf{A Lack of Focus on the User:} The research was ``technology-centric`` and ignored the real-world user. We found no research that designed a system for the *mobile mechanic*, who needs a simple, fast application that can work in a railyard with a bad internet connection.
    \item \textbf{A Naive Architecture:} Many papers did not have a good solution for the high cost, slow speed, and big privacy problems of storing *all* data on a public blockchain.
\end{enumerate}

The main goal of this thesis, therefore, was to fill these specific gaps. We did not want to write another theoretical paper. We wanted to design, build, and evaluate a \textbf{complete, full-stack, and practical prototype} that solves all three of these problems at the same time.

\section{Analysis of the Contribution}
\label{sec:conclusion_contribution}

In Chapter 3, we presented the main contribution of this thesis: our \textbf{3-tier hybrid architecture}. This system is a complete, working solution that intelligently balances the trade-offs between decentralization and practicality. Our contribution is the design and implementation of all three layers, which work together to create a single, cohesive application.

\textbf{First, we built the Data Layer.} This is our \texttt{RailwayAssetRegistry} smart contract. We wrote it in Solidity and deployed it on the Sepolia testnet. This is the ``on-chain`` heart of our system. It solves the problem of ``trust`` and ``data integrity``.
\begin{itemize}
    \item We designed a clear, hierarchical data structure (\texttt{Train} $\rightarrow$ \texttt{Wagon} $\rightarrow$ \texttt{Equipment}) that models the real-world relationships.
    \item We implemented a strong ``soft-delete`` and ``undelete`` logic, which is very important for an auditable system where you should never permanently destroy a record.
    \item We built efficient storage and search indexes. We used \texttt{keccak256} hashing for our inverted indexes (\texttt{\_wagonsByName}, \texttt{\_wagonsByType}) and used the OpenZeppelin \texttt{EnumerableSet} library to manage our relational mappings (\texttt{\_wagonsByTrain}).
    \item We made it gas-efficient by using \texttt{uint32} for IDs and modern features like \texttt{custom errors} instead of long string messages.
\end{itemize}
This smart contract is our ``immutable ledger`` and acts as the single source of truth for all asset data.

\textbf{Second, we built the Logic Layer.} This is our \textbf{backend API}, which we wrote in Python using the FastAPI framework. This backend is the ``middleware`` or ``orchestrator`` of our system. This layer is our answer to the ``naive architecture`` gap.
\begin{itemize}
    \item It creates our \textbf{hybrid model}. It manages all ``off-chain`` data, like user accounts, emails, and hashed passwords, in a private and fast SQLite database. This solves the privacy and security problem.
    \item It is the only part of the system that talks to the blockchain. It holds the server's private key and manages all the complex \texttt{web3.py} calls. This makes the system very secure and very simple for the user.
    \item It provides a fast, modern REST API for the frontend, and it handles all user authentication using \textbf{JWT tokens}.
\end{itemize}
This backend layer is the ``bridge`` that connects a normal, user-friendly web application to the complex, decentralized blockchain world.

\textbf{Third, we built the Presentation Layer.} This is our \textbf{frontend application}, which we built with React and TypeScript. This layer is our answer to the ``User Experience (UX)`` gap.
\begin{itemize}
    \item We focused on a clean, component-based design using \texttt{TailwindCSS}.
    \item We used modern state management with \textbf{React Query}. This makes the app feel very fast by caching data and updating it in the background (``stale-while-revalidate``).
    \item Most important, we built it as a \textbf{Progressive Web App (PWA)}. This is a critical feature for our target user. A mechanic can ``install`` our application on their mobile phone, and the PWA's \texttt{service-worker} provides offline caching. This means the app will still load in a railyard or a tunnel with no internet.
\end{itemize}
This PWA, with its maps, charts, and simple forms (as shown in our screenshots in Chapter 3), proves that a complex blockchain system can be made simple and practical for a non-technical user.

