Phase 3
Phase 3
Project Advisor
Presented by:
Group ID: F22BS012
Team F22BS012
Member Name Primary Responsibility
Jawad Afzal Front End Development, Research, Back End
Development
M Sheharyar Front End Development, Research, Back End
Development
Usman Shahid Back End Development, Front End
Development, Research
Product Warranty Verification using Blockchain
Table of Contents
Table of Contents ........................................................................................................................... i
Revision History ............................................................................................................................ ii
Abstract ......................................................................................................................................... iii
1. Introduction ..............................................................................................................................1
1.1 Product......................................................................................................................................... 1
1.2 Background.................................................................................................................................. 1
1.3 Objective(s)/Aim(s)/Target(s) ..................................................................................................... 1
1.4 Scope ........................................................................................................................................... 1
1.5 Business Goals............................................................................................................................. 2
1.6 Document Conventions ............................................................................................................... 2
1.7 Miscellaneous .............................................................................................................................. 2
2. Technical Architecture ............................................................................................................3
2.1 Application and Data Architecture .............................................................................................. 3
2.2 Component Interactions and Collaborations ............................................................................... 5
2.3 Design Reuse and Design Patterns .............................................................................................. 8
2.4 Technology Architecture ............................................................................................................. 8
2.5 Architecture Evaluation ............................................................................................................... 8
3. Detailed/Component Design ....................................................................................................9
3.1 Component-Component Interface ............................................................................................... 9
3.2 Component-External Entities Interface ..................................................................................... 12
3.3 Component-Human Interface .................................................................................................... 12
4. Screenshots/Prototype ...........................................................................................................13
4.1 Workflow................................................................................................................................... 13
4.2 Screens....................................................................................................................................... 14
4.3 Additional Information .............................................................................................................. 17
5. Test Specification and Results ..............................................................................................20
5.1 Test Case Specification ............................................................................................................. 20
6. Revised Project Plan ..............................................................................................................23
7. References ...............................................................................................................................24
Appendix A: Glossary..................................................................................................................25
Appendix B: IV & V Report .......................................................................................................26
Revision History
Name Date Reason For Changes Version
Abstract
Counterfeit products are a persistent problem that affects both customers and manufacturers. Not
only do fake products risk the safety of consumers, but they also damage the reputation and
revenue of manufacturers. Additionally, the traditional method of providing warranties often
leads to a complicated and time-consuming process, causing inconvenience for customers.
To address these challenges, a novel solution leveraging blockchain technology can provide a
reliable and efficient system for product authentication and warranty claims. By using smart
contracts written in the solidity language, a web application can be developed to offer unique
interfaces for manufacturers, sellers, and buyers. Customers can verify product authenticity using
a distinct code provided during purchase, while the seller can input the sale date to facilitate a
simplified warranty claim process.
This blockchain-based system can provide numerous benefits, including faster and automated
verification, increased transparency, and a secure and immutable ledger of all product
transactions. It can also potentially reduce costs and minimize fraud by eliminating
intermediaries and increasing trust between parties.
Overall, blockchain technology offers a promising solution to combat counterfeit products and
streamline warranty claims, enhancing the safety and satisfaction of customers while improving
the reputation and revenue of manufacturers.
1. Introduction
1.1 Product
Like many others, I have fallen victim to the sale of fake products by dishonest merchants in
the market. Currently, there is no digital method for authenticating products. Additionally,
claiming a warranty for products requires keeping the warranty card safe. This instigated the
idea that there should be a digital system that can be used to solve these problems using
technologies like blockchain where data is immutable and safe.
1.2 Background
The identification of fake products has always been a challenge. As per the EU Intellectual
Property Office and the Organization for Economic Cooperation and Development, the
worldwide sales of counterfeit or pirated products have increased dramatically to 460 billion
euros, representing approximately 3.3% of all international trade. This has caused significant
harm to businesses across the world, with the clothing and pharmaceutical sectors incurring
losses of 26.3 billion euros and 10.2 billion euros, respectively. Furthermore, the advancement
of technology and e-commerce has led to an exponential increase in the market for counterfeit
products online.
Databases can easily be manipulated, and gaining unauthorized access into the traditional
databases in this era is not difficult.
1.3 Objective(s)/Aim(s)/Target(s)
Upon the Completion of this project following targets will be achieved:
1.4 Scope
Research shows that the market for fake products has rapidly exploded. The sales of
permeated products are around 460 billion euros annually. The development of this product
will the ensure eradication of these products from the market. The proposed business model
for this software would be a subscription charge charged from the seller at the time of
registration and the manufacturer would pay in accordance with registering the products on
the website.
1.7 Miscellaneous
NA
2. Technical Architecture
2.1 Application and Data Architecture
Class Diagram:
Figure 2.1
ER DIAGRAM:
Figure 2.2
This project is primarily built on blockchain technology, and as such, it has limited reliance on
traditional database systems. However, a traditional database is being used instead of blockchain to
avoid incurring additional gas costs. The given class diagram and the entity relationship diagram
describe the required database schema for facilitating the registration of the login processes of the
manufacturer and the seller. These include attributes such as a unique id, name, password, email,
and phone number for each manufacturer and seller. It also explains the attributes of the product
whose database is being created, primarily for the purpose of storing the selling date that can later
be used for the purpose of claiming a warranty. Additionally, the diagram also explains the necessary
attributes of the administrator.
ACTIVITY DIAGRAM:
Figure 2.3
The diagram above represents the working model of the project under discussion. As the
diagram represents, an individual, whether a manufacturer or a buyer, has to log in to be
granted access to the system. If they have a login already, they may sign in to continue,
alternatively, if they aren’t already signed up, they may use the provided option to do so.
Once logged in, a manufacturer will be provided with an option to enter the product details.
As soon as that is done, the product will be registered successfully.
A seller will have the option to enter the product details which will show up since the
manufacturer will have entered them by the time the product reaches the seller. At the time of
sale, the seller will enter the date of sale, once this process is complete, the product will be
registered as sold.
The buyer may enter the product details and get the resultant verification.
SEQUENCE DIAGRAM:
Figure 2.4
The diagram above represents the working model of the project. As the diagram represents, an
individual, whether a manufacturer or a buyer, has to log in to be granted access to the system. If
they have a login already, they may sign in to continue, alternatively, if they aren’t already signed
up, they may use the provided option to do so.
Once logged in, a manufacturer will be provided with an option to enter the product details. As
soon as that is done, the product will be registered successfully.
A seller will have the option to enter the product details which will show up since the manufacturer
will have entered them by the time the product reaches the seller. At the time of sale, the seller will
enter the date of sale, once this process is complete, the product will be registered as sold.
The buyer may enter the product details and get the resultant verification.
DFD:
Figure 2.5
There are multiple user authentication models that exist at the moment, one of these user
authentication models could be reused to authenticate the users if it adheres to security
guidelines. Since this isn’t a major aspect of this project and is only used to allow authorized
access, reusing such a model won’t affect the overall work.
It is a blockchain-based system that uses smart contracts written in solidity. These smart contracts
include features like unique ids and names of products. The smart contracts will be tested on the
testnet before deploying them on the mainnet.
In addition to this MongoDB is being used for the purpose of storing data. The purpose of using
traditional databases instead of blockchain for these purposes is to avoid access gas costs.
The overall architecture working includes a manufacturer who is registered on the platform, who
will register the product, and upon registration smart contracts would be deployed. In addition, the
seller, who is also registered with the system, can add the selling date of the product. This data can
later be used for warranty claim purposes. The buyer/customer could use his interface to verify the
authenticity of the product.
This project largely works on blockchain but the traditional database is also being used in some
instances. This approach makes the product efficient and secure while minimizing gas costs.
Blockchain technology serves to verify the authenticity of products and ensure the system is tamper-
proof, while the traditional database stores the data about the sale date of the product for future
warranty claims. This hybrid approach creates an affordable, accessible, and secure system that can
help streamline the warranty verification process.
Using a traditional database to store data about product sale details reduces the need for additional
gas costs associated with blockchain transactions. Similarly, by using blockchain technology to
verify the authenticity of the products, the system prevents any attempt to manipulate the verification
process. Blockchain technology provides a secure, tamper-proof environment that ensures the
integrity of the system. Any attempt to modify the system’s data will be immediately detected and
rejected.
3. Detailed/Component Design
3.1 Component-Component Interface
Flowchart:
Figure 3.1
The given flowchart explains the operation process of the project, which primarily caters to three
distinct users: the manufacturer, the seller, and the buyer. To access the platform services, both the
manufacturer and the seller must first register themselves using the signup feature provided on the
website. Upon registration, the administrator will validate the authenticity of the manufacturer and
seller’s credentials and if successful, the manufacturer and the seller will be duly registered on the
platform.
After the successful registration, both the manufacturer and the seller will be able to log in to the
website. After successful login, the manufacturer and the seller can proceed to register the product
and the seller can add the selling date of the product.
Figure 3.2
Pictorial Representation:
Figure 3.3
4. Screenshots/Prototype
4.1 Workflow
Figure 4.1
4.2 Screens
About us Pages:
Figure 4.4
Figure 4.5
Services Pages:
Figure 4.6
Figure 4.7
Figure 4.8
Figure 4.9
Figure 4.10
Figure 4.11
Figure 4.10
The above smart contracts were developed in reference to the 5 types of electronic products needed
for the project. Each smart contract represents one electronic i.e., Laptops, Smart Watches,
Gaming Consoles, Mobiles, and TVs.
All of these smart contracts were written on solidity using the Remix IDE and were deployed to
beta-test the working. This concludes the back-end in reference to the smart contracts thereby
keeping in conjunction with the project timeline provided at the start of the project.
Identifier TC-1
Related requirements(s) NA
Short description Sign-in
Pre-condition(s) User registered
Input data Email, password
1) User enters email
Detailed steps
2) User enters a password
Expected result(s) Successful login
Post-condition(s) Specific dashboard appears
Actual result(s) Successful login
Test Case Result PASS
Identifier TC-2
Related requirements(s) NA
Short description Deployment of Smart Contracts
Pre-condition(s) Manufacturer Logged in
Input data Unique ID, Name
1) User enters unique ID
Detailed steps
2) User enters a Name
Expected result(s) Smart Contract Deployed
Post-condition(s) Smart contract available on remix
Actual result(s) Successful deployment
Test Case Result PASS
Identifier TC-3
Related requirements(s) NA
Short description Deployment of Smart Contracts
Pre-condition(s) Manufacturer Logged in
Input data IMEI, Name
1) User enters IMEI
Detailed steps
2) User enters a Name
Expected result(s) Smart Contract Deployed
Post-condition(s) Smart contract available on remix
Actual result(s) Successful deployment
Test Case Result PASS
Identifier TC-4
Related requirements(s) NA
Short description Deployment of Smart Contracts
Pre-condition(s) Manufacturer Logged in
Input data IMEI, Name
1) User enters IMEI
Detailed steps
2) User enters a Name
Expected result(s) Smart Contract Deployed
Post-condition(s) Smart contract available on remix
Actual result(s) Successful deployment
Test Case Result PASS
Identifier TC-5
Related requirements(s) NA
Short description Deployment of Smart Contracts
Pre-condition(s) Manufacturer Logged in
Input data Unique ID, Name
1) User enters a unique ID
Detailed steps
2) User enters a Name
Expected result(s) Smart Contract Deployed
Post-condition(s) Smart contract available on remix
Actual result(s) Successful deployment
Test Case Result PASS
Identifier TC-6
Related requirements(s) NA
Short description Deployment of Smart Contracts
Pre-condition(s) Manufacturer Logged in
Input data Unique ID, Name
1) User enters unique ID
Detailed steps
2) User enters a Name
Expected result(s) Smart Contract Deployed
Post-condition(s) Smart contract available on remix
Actual result(s) Successful deployment
Test Case Result PASS
Figure 7.1
The picture above is a Gantt chart that illustrates the progress which has been made in the development of the
project. The first phase, which involved analysis and initial documentation has been completed. The second phase,
which entailed back-end development and deployment of smart contracts has also been accomplished. In the third
phase which has now been finished, the front end and the required interface were created. Currently, we are
working on integrating the back end and the front end and then we will proceed to testing and debugging.
Status
Module Name
(Complete, Partially Implemented, Not Implemented)
Module 1 (Back-End Development) Complete
Module 2 (Front-End Development) Complete
Module 3 (Front-End and Back-End
In progress
integration)
Complete System In progress
7. References
1. https://arxiv.org/pdf/2206.08565.pdf#:~:text=A%20consumer%20can%20verify%20the,product%20
linked%20to%20the%20Blockchain.&text=Over%20the%20years%2C%20the%20identification,for
%20all%20supply%20chain%20stakeholders
3. https://erdplus.com/
4. https://remix.ethereum.org/
5. https://teamgantt.com/
6. https://creately.com/
7. www.visual-paradigm.com
Appendix A: Glossary
• Authentication: the process of proving something true
• Instigated: initiated
• Permeated: fake
Name Signature
Fix Time
S# Defect Description Origin Stage Status
Hours Minutes
1 Solidity functions were not working because Fixed 0 45
wrong version of solidity was selected
• High-level Technical Design, Centers for Medicare & Medicaid Services. (www.cms.gov)