## 6 Developing the dNAS Prototype
### The Decentralized Functional Smart Contracts  
Smart contracts, hosting functional methods, have the core functional code to become fully decentralized and delegated to all the trusted authorities of the consortium and its blockchain network. Every blockchain node on the dNAS blockchain network must agree on the current state of the smart contract storage. This should be done in accordance with the smart contract mechanism and workflows, such as the source code compiled with the Solidity compiler and run by the Ethereum Virtual Machine of every blockchain node of the network, as described in Figure 14.  
The smart contract source code, deployed to the blockchain network, is implemented in Solidity, with the Truffle framework as its development environment and automated testing library. There are typically three smart contracts developed in dNAS, so as to cover every operation defined in the initialization phase and data process phase, namely (1) the _\"WineDataContract\"_ for wine data operations, (2) the _\"PeerRegistryContract\"_ for the consortium registry management, and (3) the _\"Proxy\"_ which enables a proxy pattern for the purpose of smart contract upgradability. In order to perform those operations defined under the data processing phase, the design patterns of mapping storage are defined in smart contracts, with individual data types also specified, such as the _\"WineDataHash\"_, which is the content hash (_Content ID_)  
Figure 14: The Workflow of Ethereum Smart Contract Source. obtained from any IPFS process representing a specific wine record subset mapped to a unique wine identifier, which could also be further mapped per different write counts as _\"iteration\"_. Similar design patterns of mapping storage could be found to apply to the public key of the previous processing node, which is also a registered node of dNAS along the supply chain, and to identifiers of different tags and devices. The _\"currentImplementation\"_ and _\"initializeCounter\"_ are in place according to the proxy pattern, which is used to check if a contract address has already been initialized previously. Events are also defined in the _\"WineDataContract\"_, and will be emitted when the on-chain process of the wine record creation or appending is completed. The events emitted in either of the operations are then captured by the event listener defined in the blockchain service. The creation process will include both the public address and hashed device identifier creating the wine record in its event, while the appending process will include both previous and current public addresses of the wine record. Proceeding with the definition of individual methods, according to the wine record creation process, a specified wine identifier is checked and to validate if any records for the identifier have already been logged on-chain with the _\"require\"_ statement. The individual variables mapped to the wine identifier are then updated with parameters, including a content hash obtained from IPFS node (_WineDataHash_), the public address, tag identifier and device identifier, of the request payload. The on-chain wine record creation process in Algorithm 1, is completed by incrementing the write count so that it matches the counterpart stored in the NFC tag, with the creation process also being emitted. ```
Input :wineld, wineDataHash, newPublicAddress, tagId, deviceld Output :Boolean result of create operation ifMapWriteCount(wineld)==0 then \(MapPubAddr(wineld)\gets newPublicAddress; MapDataHash(wineld)\gets wineDataHash; MapTagId(wineld)\gets tagId; MapDeviceId(wineld)\gets deviceld; MapWriteCount(wineld)+=1; emitevent; returntrue; else return(err,errMessage);
```  
**Algorithm 1**Creating On-chain Wine Record Entry  
In case a wine record is stored on-chain for a specific wine identifier with the corresponding physical wine product moved downstream to specific supply chain participants, the wine record must be validated with the wine record validation processes previously detailed.