## 5 Implementation
### Practical Deployment  
Our framework was built on the Polkadot platform, version 0.9.40, and _ink!_ version 4 was used for smart contract development. The user interface created with _Polkadot.js_[32] interacts with these smart Contracts to execute operations on the blockchain. All involved parties need to operate a _parachain_ node as well as a MongoDB database. These parties communicate with the system backend via the smart contract on the blockchain and MongoDB. A central MongoDB database at the backend acts as a directory, listing all participants in the supply chain. During the transactions, the backend is responsible for managing the communication with smart contracts, and it ensures that the database of the initiating party is updated accordingly. Having a dedicated database for each participant enhances the efficiency of data access locally and reduces the costs incurred from frequent blockchain queries. In the case of a database outage, the critical information remains accessible on the blockchain, safeguarding against data loss. A critical authentication operation is required when a user requests information from the supply chain through the backend. This is facilitated via the smart contract that holds a register of user permissions associated with the corresponding user account. After a successful authentication process, an access token is issued by the smart contract, thereby granting the backend permission to retrieve the requested data. Figure 3 shows the developed web portal. The system is comprised of a front-end interface wherein the stakeholders possess the capability to upload MPs and effectuate the creation and transfer of products among various proprietors. Participants are required to authenticate themselves through their Polkadot wallet account as an identity credential. Manufacturers, in turn, have the capability to produce an MP for their respective products and subsequently commit it to the IPFS, whereby the CID is generated as a reference for the product. The front-end also displays an inventory of products currently owned by the authenticated account holder. Each product also contains a comprehensive record of the product's history derived from the blockchain, including the preceding owner and its status within the supply chain. Figure 3: Web portal for the stakeholders. The framework employs a backend server to store a database for more effective data retrieval since not every piece of information resides on the blockchain and the IPFS does not offer traditional database-querying capabilities. The use of backend servers in our framework does not lead to a single point of failure provided that the product identifier (_product_id_), which acts as a key on the blockchain for mapping, is available. With this _product_id_, the IPFS reference can be fetched from the blockchain, and product specifics can be obtained from the IPFS. This process of information retrieval from the blockchain and the IPFS allows for the validation of a product's authenticity and tracks its origin. The system's process is depicted in Figure 4, highlighting four primary operations. They are: adding a product to the blockchain, altering the ownership of a product permanently or temporarily, fetching details about the product (MP), and confirming the product's details on the blockchain. In the process of adding the product, we assume that every product has a unique ID. As the manufacturer enters product details (step 1.1), the system generates its MP, and the system sends it to the IPFS (step 1.2) and retrieves the respective file reference from the IPFS (step 1.3). When the backend receives the IPFS reference, it sends this through the smart contract to the blockchain (steps 1.4 and 1.5).