## 5 System Implementation
### Data-Processing Phase
#### 5.2.2 Wine Record Validation Process  
Once a wine record is created off-chain and on-chain by the registered node of a winemaker role, with the tag-writing process completed, those bottled wine products are then shipped to the next node along the supply chain. Assuming the next node along the supply chain is a registered node of dNAS as well as a member of the consortium, such as the Registered Node B described in Figure 13, the corresponding wine record of an incoming wine product would then be brought into a validation process, performed on its wine record, before the wine product itself can be accepted or purchased, via the NFC-enabled _ScanWINE_ mobile application. The registered nodes of the supply-chain-participant role and wine-consumer role will then scan the NFC tags with _ScanWINE_ to update the state of that wine record. _ScanWINE_ is the only entry point for registered nodes of both roles to transit the state of a wine record, unlike the registered nodes of winemaker role, which could utilize the database-operating  
Figure 13: The Wine Record Validation Process. web application to create and manage wine records. Such a wine record validation process is a _three-layered validation process_, against (1) the data stored in the database of app-backend service, (2) the on-chain storage, and (3) the updated wine record subset stored on the IPFS network. When a registered node logs into _ScanWINE_ on its device and scans the NFC tag of an incoming bottled wine product, it will automatically get through the password protection applied to the NFC tag, as the static password is always injected during the tag-reading process. The data written to the tag, mentioned in the creation process, will then return to _ScanWINE_, after which they can validate the wine record based on the data retrieved from the NFC tag. An off-chain validation process against the wine record will then take place to compare the retrieved tag data and those stored in the dedicated database of a shared instance of app-backend service. An error, classified as (1) modification attack, if wine identifier and the signature are inconsistent with the counterparts stored in the database, (2) reapplication attack when either the _\"write_counter\"_ or _\"read_counter\"_ is different from that of the wine record stored in the database, or (3) cloning attack, when an inconsistent tag identifier is found, would be returned to the app-backend service, and the _\"unsuccessful_validation_data\"_ of the corresponding wine record will consequently be updated, with an error message shown on the user interface of _ScanWINE_ application. The on-chain validation processes of that wine record will therefore be initiated, provided that the off-chain validation process is completed successfully. The app-backend service will send a request to the blockchain service via its _\"validate\"_ endpoint, which will further invoke the _\"validate_wine_record\"_ method of the deployed smart contract, named _\"wine_data_contract\"_, with _\"tag_data\"_ as the payload. The public address of the last registered node handling the wine product, which was involved in producing the signature from _\"tag_data\"_, is then recovered on-chain with the identifiers of both the wine product and corresponding tag of _\"tag_data\"_. The recovered public address is then validated against its counterpart, stored on-chain under the same wine identifier in a dedicated mapping storage on the smart contract.