A vehicle's value is to a great extend determined by the miles driven and the service history. Historically paper-based log books have been used to keep a record, but fraudulent vehicle dealer like to manipulate them to pretend a lower milage and better service history in order to gain a higher price. In addition, blank vehicle service history log books are easily available to everybody on ebay which makes this fraud even easier to carry out.
To fix this process a blockchain based system shall be developed. Blockchain based system have quite some outstanding features, with most of them being highly desireable for this application:
- multiple parties need to share a joint view on a dataset
- tamper proof data : no entry can be changed once it has been added
- tamper proof system behavior : once deployed, the code which is defining the behavior of the system, can not be changed
- each data entry and code deployment is time stamped
- decentralized : there is no single system which cab fail
- open : all code and data is openly accessible and thus verifiable
- consorship resistant : nobody can stop the system
- Vehicle Manufacturer (roles: creator, seller)
- Vehicle Owner (roles: log entry provider, seller)
- Service Provider (roles: log entry provider, seller, (user) )
- (temporary user of the vehicle - optional - future extension)
Allowed users : Vehicle Manufacturer
(The initial version may assume that there is only one Vehicle Manufacturer.)
1.1 Vehicle Manufacturer creates a new instance of a vehicle providing initial immutable data of the vehicle:
- vehicle id
- make
- model
- chassis number
- engine number
1.2 Vehicle Manufacturer becomes owner of the vehicle.
Allowed users : Owner
2.1 designate (temporarely) a vehicle's service provider which will be allowed to conduct the service and to add log entries to the vehicle's service history.
To revoke, service provider needs to be set to 0.
Allowed users : Service Provider, Owner (for self-service tasks)
3.1 add a log entry to the service history providing the followind data
- odometer reading
- descrition of performed tasks
- URI to additional documents (PDF-file or image)
Allowed users : any
4.1 get last log entry for a vehicle (specified by its id)
4.2 return log entry id (= number of current log entries)
Allowed users : any
5.1 get a certain log entry for a vehicle
Allowed users : Owner
6.1 offer vehicle for sale by providing
- status update (for sale = true)
- set requested price (in Wei)
Allowed users : any
7.1 user accept offer by sending at least the requested amount to current vehicle owner
7.2 return potential surplus amount to buyer (full amount if it was less than requested price)
7.3 transfer ownership of vehicle to buyer
Allowed users : Owner
8.1 remove vehicle from existence
For the outlined requirements, an implementation based on Non-Fungible-Token (NFT) as defined in ERC721 seems to be a perfect fit.
Every ERC-721 compliant contract must implement the ERC721 and ERC165 interfaces:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md
Given the limited time to implement this projects as well as the fact that the standard is pretty new, and to reuse as much implementation knowledge and effort which has been made available on this new topic so far, the ERC721Token library implementation from OpenZeppelin will be used for this project.
The ERC721Vehicle contract will inherit from the ERC721Token, which will give it basic NFT functionaliy. ERC721Token inherits from ERC721BasicToken and implements the interfaces ERC721, ERC721Enumerable and ERC721Metadata. To get a better overview, a UML class/contract diagram has been created which can be found in the UML folder.
For ease of development and testing within Remix all contracts, including the contracts from the ERC721 library implementation of OpenZeppelin reside as local files in the contracts folder. Running remixd pointing to the local contracts folders (easily being done on Linux using the provided remixd.sh file), enables the possibility to link Remix to this local folder. This allows using all functions of the contract with the generated UI. With this setup, the local files can at the same time be accessed by other editors and tools like truffle. Changes either in Remix or any tool working on the local files will be synced in both directions.
Initially only the contracts were developed using Remix with the described setup.
Following that, the contracts were integrated into a truffle project structure (generated by truffle init).
During following interations, a few integrations and evaluations with various React project folder structures and boiler plates were conducted, with finally using a truffle + React + next.js setup based on a truffle-next box.
The current (very basic) Web Frontend can work with locally deployed contracts and will automatically switch to the contract on Rinkeby when that network is selected on MetaMask.
At this stage the React + Next.js Web UI demonstrates the following basic features.
- display current MetaMask account
- get current Balance
- simple transaction of storing a predefined value and retrieving it again
- generate new Vehicle Token*, autoincrement the 'ein', retrieve last tokenID and getLastVehicle Data (*This function is actually restricted to the deployer of the contract. If you want to use the deployed and preconfigured contract then you have to use the wallet mnemonic in
.envrc- please do not drain all the funds.) - History Log Entries could be retrieved but feature for creating entries is still missing
Many more features of the underlying smart contract can be accessed by using Remix to auto-generate a UI.
More information and guidance is documented in test_process_documentation.md within the documentation directory.