A Simulated Organic Vegetable Production and Marketing Environment by Using Ethereum
<p>All roles and the Ethereum smart contract of the simulated system.</p> "> Figure 2
<p>A simulated scenario of production and marketing of organic vegetables.</p> "> Figure 3
<p>Function and accessibility of every role in the Traceability Agricultural Product (TAP) contract.</p> "> Figure 4
<p>Function and accessibility of every role in the organic vegetable contract (ownership for farmer).</p> "> Figure 5
<p>Organic vegetable contract, ownership is retailer.</p> "> Figure 6
<p>Flow chart of blockchain function and algorithm used in organic vegetable TAP.</p> "> Figure 7
<p>Register and TAP view in proposed system.</p> "> Figure 8
<p>Organic vegetable information view in proposed system.</p> "> Figure 9
<p>Organic vegetable transaction in proposed system.</p> "> Figure 10
<p>Organic vegetable transaction checks in proposed system.</p> "> Figure 11
<p>Scenario of transaction.</p> "> Figure 12
<p>Organic vegetable argument in proposed system.</p> ">
Abstract
:1. Introduction
- The record of organic vegetable production and sales cannot prove authenticity.
- The prices of organic vegetables are increased.
- Agricultural ecological environment pollution problems are caused.
- The purposes of this study are as follows:
- To propose an organic vegetable production and marketing system based on Ethereum.
- To integrate and analyze the system on the Ethereum platform.
2. Blockchain Technology
- Peer-to-peer (P2P): in a peer-to-peer network, all nodes communicate with each other. This network deals with other nodes and can be decentralized without using third party software. In other words, the status of each node in the network is the same. No node belongs to the central control position, and no other node needs to serve an intermediary role in the transaction. Nodes in a blockchain network can join or exit based on their will, and nodes can perform most of the functions. If a node is damaged, added, or removed, the operation of entire system is not affected. Instead, the robustness of the network increases with the number of nodes.
- Participants in the blockchain network: two types of participants exist in the blockchain network. The first type of participant is a user and serves the functions of money transfer (e.g., Bitcoin and Ether) and execution currency remittance. The second type of participant is a miner. A miner functions as a production block and gets paid.
- Transaction: this command is issued by the user while making money remittances and is transmitted through each node in the blockchain network. A transaction includes the following stages in its lifecycle: establishing a transaction, naming it, passing it, and saving it in a block. First, the transaction is established, and then, the transaction command is passed to each node. After receiving the transaction node, the system checks whether the transaction meets certain conditions. If the conditions are met, a success message is sent back to the transaction source node, and the transaction command is passed to each node. If the conditions are not met, the discarded message is returned, and the transaction command is not passed to other nodes. The final transaction is verified by the miner and recorded on the blockchain, and the block is passed to each node, which is recorded on a decentralized ledger.
- Mining: the production of a new block is known as mining. If mining is successful, additional money is generated, and the miner earns the currency as a handling fee. There can be only one miner in the new production block, and only that miner can earn the handling fee. To earn the handling fee, many miners compete for obtaining new blocks. However, the production of new blocks requires high computing power. Therefore, in mining, there is a saying that “miners compete with each other to produce blocks.”
- Decentralized ledger: in the blockchain network, all transferred blocks are stored on the node’s ledger. The information of the preceding block is stored in each block. By referring to the preceding block through the hash value, the blocks are connected to each other in a chain format. Each node stores the record of all transactions, and the contents of all ledgers are exactly the same, which represents the consensus mechanism of the blockchain. All the transaction information in the decentralized ledger is encrypted, transparent, non-tamperable, and reliable. If a ledger is damaged, the record can be viewed on other nodes; hence, there is no downtime. Decentralized ledgers can be applied to financial insurance, medical health, government and public welfare, copyright and ownership, academic and human resource management, shared economies, and Internet of Things.
- Encryption hash: a hash function is an encryption technique in the blockchain network. Common hash algorithms are SHA-256, RIPEMD-160, and HASH160. A characteristic of a hash function is that the input string has an arbitrary size, but the size of the output string is a fixed. For an input value, a completely unrelated output value known as the hash value is obtained. By using collision resistance, two different outputs must be produced for two different inputs. The function also has hidden or irreversible characteristics. Moreover, it is highly difficult to trace back the original input from the hash values. The hash algorithm can be used to verify whether the message has been tampered. Moreover, the verification can be simplified using a Merkle tree. A Merkle tree repeats the hashing process of thousands of transactions by forming new hash values in pairs and finally produces a final set of hash values. Hence, the Merkle tree can substantially reduce the amount of resource consumption during transmission and computation. A blockchain mainly uses the elliptic curve digital signature algorithm. The node user in each blockchain possesses both public and private keys. The public key is known to other users in the blockchain network. The node user must know the private key to receive currency, sign electronically, and send money. This key should not be disclosed to the others in the network. While trading, the preceding transaction and payee’s public key must be hashed to create a digital signature, which is added to the back of an electronic money digital signature.
- Timestamp: a timestamp is used to ensure that the block sequence is written on blocks. Each block is hashed and then a timestamp is added and passed. This timestamp is used to prove the validity of data at a specific time. Each timestamp is hashed with the previous timestamp, which is then hashed with the next timestamp. Thus, a chain that ensures a sequence of blocks is formed. If a timestamp is generated for a block, the block cannot be modified. If the block hashed value does not match, the decentralized ledger immediately detects that tampering has occurred.
3. Simulated System of Organic Vegetable Production and Marketing
3.1. Case Study from Albertsons Companies
3.2. Simulated System Overview
- Farmer: the functions of a farmer include purchase, registration, production, sales, and updating. In the purchase function, farmers buy organic fertilizers and seeds from fertilizer traders and seed traders. In the registration function, farmers are responsible for registering the organic vegetable production and sales resume information into the Ethereum network. Farmers are responsible for all processes of producing organic vegetables. In the sales function, farmers sell organic vegetables to consumers or middlemen. In the updating function, farmers are allowed to update the organic vegetable production and sales resume information pertaining to the seed information, fertilizer information, fertilization records, organic vegetable sale prices, and update the ownership details of the organic vegetables.
- Intermediary: the functions include purchase, sale, and updating. In the purchase function, organic vegetables are bought from farmers. In the selling function, these vegetables are sold to retailers. In the updating function, the middlemen update the organic vegetable production and sales resume information in terms of the price at which the organic vegetables are sold and update the ownership details of the organic vegetables.
- Retailer: the functions include purchase, sale, and updating. In the purchase function, organic vegetables are purchased from middlemen. In the sales function, the vegetables are sold to consumers. In the updating function, retailers update the organic vegetable production and sales resume information in terms of the price at which the organic vegetables are sold and update the ownership details of the organic vegetables.
- Consumer: the functions include purchase and updating. In the purchase function, organic vegetables are purchased from farmers or retailers. In the update function, consumers update the ownership details of the organic vegetables. This study defines that consumers are not the ultimate organic vegetable owners. Therefore, it allows first-hand purchasing or even auctions. Products are still resold to other consumers after purchase, so consumers can update the price or ownership of organic vegetables.
- Organic inspection agency (OIA): the functions include soil testing, water quality testing, organic vegetable testing, and adding functions. The soil and irrigation water in the environment in which organic vegetables are produced must pass organic standards. An OIA should be involved to conduct on-site inspections. Before selling organic vegetables, the vegetables must first be sent to an OIA for organic testing. The new feature allows organic inspection agencies to add inspection results to the organic vegetable production and sales resume information.
- Arbitrator: when all transactions are in dispute, the system requires an arbitrator to transfer the controversial Ether to the arbitrator. Subsequently, the arbitrator assesses the right and wrong parties in the dispute. The dispute may be because the payment is completed and the consumer did not receive the organic vegetables.
- Ethereum smart contract: in this system, the smart contract is divided into Traceability Agricultural Product contract (TAP contract), organic vegetable contract, and manage contract.
3.3. Smart Contract Design
4. Implementation
4.1. Registered and Update Tap
Algorithm 1: Registered TAP |
Input: msg.sender, farm_num Output: str 1 if msg.sender = Farmer then 2 if farm_num = 0 then 3 register TAP information(farm_num, Seed info.) storage in the TAP Contract. 4 str = regTAP success!!! 5 else 6 str = farm_num can’t repeat!!! 7 end 8 end 9 return str |
Algorithm 2: Update TAP |
Input: msg.sender, farm_num Output: str 1 if msg.sender = Farmer then 2 if farm_num = 0 then 3 str = farm_num no register!!! 4 else 5 input production record to TAP(Fertilization, Irrigation, etc.) storage in the TAP Contract. 6 str = updataTAP success!!! 7 end 8 else 9 str = Permission denied!!! 10 end 11 return str |
4.2. OIA Addition Result
Algorithm 3: Organic Inspection Agency add result |
Input: msg.sender, farm_num, state, record Output: str 1 if farm_num = 0 then 2 str = farm_num no register!!! 3 else 4 if msg.sender = OrganicInspectionAgency then 5 if state = false then 6 if record > 0 then 7 input organic vegetables inspection result storage in the TAP Contract. 8 state = true 9 str = addResult success!!! 10 else 11 str = No production record!!! 12 end 13 else 14 str = test results have been completed!!! 15 end 16 else 17 str = Permission denied!!! 18 end 19 end 20 return str |
4.3. Organic Vegetable Transaction
Algorithm 4: Organic vegetables Transaction(register) |
Input: msg.sender, ov_ID, state Output: str 1 if msg.sender = Farmer then 2 if ov_ID = 0 then 3 register organic vegetables information(weight, price, etc.) storage in the Organic Vegetables Contract and Manage Contract. 4 state = true; str = regOV success!!! 5 else 6 str = ov_ID can’t repeat!!! 7 end 8 else 9 str = Permission denied!!! 10 end 11 return str |
Algorithm 5: Organic vegetables Transaction (payable) |
Input: msg.sender, ov_ID, msg.value, argue, state Output: str 1 if msg.sender = Owner then 2 str = activate failure!!! 3 else 4 if ov_ID = 0 then 5 str = ov_ID no register 6 else 7 if argue > 0 then 8 str = arguing… 9 else 10 if state = true then 11 Transfer msg.value to the Organic Vegetables Contract and update Manage Contract state. 12 state = false 13 str = activate success!!! 14 else 15 str = activate failure!!! 16 end 17 end 18 end 19 end 20 return str |
Algorithm 6: Organic vegetables Transaction(withdraw) |
Input: msg.sender, state Output: str 1 if msg.sender = Owner then 2 Transfer the Organic Vegetables Contract balance to Owner’s wallet, update Manage Contract state and change organic vegetables ownership. 3 state = true 4 str = withdraw success!!! 5 else 6 str = Permission denied!!! 7 end 8 return str |
4.4. Dispute Resolution
Algorithm 7: Dispute resolution |
Input: msg.sender, ov_ID, reason, state Output: str 1 if ov_ID = 0 then 2 str = No ov record 3 else 4 Input dispute reason, argue caller information to Organic Vegetables Contract and update Manage Contract state. 5 Transfer the Organic Vegetables Contract balance to Arbitrator and update Manage Contract state. 6 state = false 7 str = argue success!!! 8 end 9 return str |
5. Testing and Validation
5.1. Register and View TAP
5.2. Organic Vegetable Transaction
5.3. Dispute Level
5.4. Security Analysis
- Reentrancy attack: the call. value() method is used to determine the balance in the contract. If the user updates the sender’s balance after transmitting the balance, an attack will take effect. Note that call. value() can transmit all available gas by default, and the amount of gas transferred can be adjusted. Transfer() and send() only allow 2300 gas to be used and cannot adjust the amount of transmissions. This amount of transmissions is only sufficient to generate an event log and a transmission exception when a transmission fails. Therefore, re-entry attacks are avoided. The system uses the transfer() and send() methods, so there is no risk of re-entry attacks.
- Overflow and underflow: overflow occurs when the unit 256 type variable is greater than 256 bits. This variable changes to zero. Alternatively, when the quantity one is subtracted from a memory location containing the number 0, underflow occurs; attempts to manage underflows or overflows in Ether are very dangerous.
- Therefore, the system does not add or subtract when processing the price and has a judgment of not less than zero and not more than two while setting the price. Thus, there is no risk of a numerical overflow.
- Replay attack: in this event of repeated data transmissions, the system cannot effectively prove that this data has been received; this is referred to as a replay vulnerability. The attack is mainly conducted after the branching of the blockchain. The two parties share and trade the same data, but they do not exchange messages. This vulnerability has been added to protect against this attack since Geth 1.5.3. This study used Geth 1.6.5, thus confirming that there is no such security issue.
- Access restriction: this restriction is used for functions. For example, the access restriction feature is used only when the address of the contract is established to enforce the limits of the function. In 2017, the e-wallet parity suffered serious damage because no access restrictions were set. To prevent this vulnerability, the OVPMS system has a set access restriction while calling functions.
6. Conclusions
Author Contributions
Funding
Conflicts of Interest
References
- Hernández, A.F.; Parrón, T.; Tsatsakis, A.M.; Requena, M.; Alarcón, R.; López-Guarnido, O. Toxic effects of pesticide mixtures at a molecular level: Their relevance to human health. Toxicology 2013, 307, 136–145. [Google Scholar] [CrossRef] [PubMed]
- Lumpkin, H. Organic Vegetable Production: A Theme for International Agricultural Research. FAO Corporate Document Repository, 2005. Available online: http:www.fao.org/DOCREP/006/AD429E/ad 429e13.htm (accessed on 9 May 2019).
- Li, J.; Wang, X. Research on the Application of Blockchain in the Traceability System of Agricultural Products. In Proceedings of the 2nd IEEE Advanced Information Management, Communicates, Electronic and Automation Control Conference, Xian, China, 25–27 May 2018. [Google Scholar]
- Dipeolu, A.O.; Philip, B.B.; Aiyelaagbe, I.O.O.; Akinbode, S.O.; Adedokun, T.A. Consumer awareness and willingness to pay for organic vegetables in SW Nigeria. Asian J. Food Agro-Ind. 2009, 10, S57–S65. [Google Scholar]
- Shafie, F.A.; Rennie, D. Consumer perceptions towards organic food. Procedia Soc. Behav. Sci. 2012, 49, 360–367. [Google Scholar] [CrossRef]
- Piyasiri, A.G.S.A.; Ariyawardana, A. Market potentials and willingness to pay for selected organic vegetables in Kandy. Sri Lankan J. Agric. Econ. 2002, 4, 1–14. [Google Scholar] [CrossRef]
- Kotler, P.; Armstrong, G.; Wong, V.; Saunders, J. Principles of Marketing, 5th ed.; Financial Times/Prentice Hall: Upper Saddle River, NJ, USA, 2008. [Google Scholar]
- Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Available online: https://reurl.cc/6jAZr (accessed on 13 November 2019).
- Chen, W.; Zheng, Z.; Ngai, E.C.-H.; Zheng, P.; Zhou, Y. Exploiting Blockchain Data to Detect Smart Ponzi Schemes on Ethereum. IEEE Access 2019, 7, 37575–37586. [Google Scholar] [CrossRef]
- Hu, W.; Fan, Z.; Gao, Y. Research on Smart Contract Optimization Method on Blockchain. IT Prof. 2019, 21, 33–38. [Google Scholar] [CrossRef]
- Hu, Y.; Manzoor, A.; Ekparinya, P.; Liyanage, M.; Thilakarathna, K.; Jourjon, G. A Delay-Tolerant Payment Scheme Based on the Ethereum Blockchain. IEEE Access 2019, 7, 33159–33172. [Google Scholar] [CrossRef]
- Pinna, A.; Ibba, S.; Baralla, G.; Tonelli, R.; Marchesi, M. A Massive Analysis of Ethereum Smart Contracts Empirical Study and Code Metrics. IEEE Access 2019, 7, 78194–78213. [Google Scholar]
- Wang, S.; Pei, R.; Zhang, Y. EIDM: A Ethereum-Based Cloud User Identity Management Protocol. IEEE Access 2019, 7, 115281–115291. [Google Scholar] [CrossRef]
- Hasan, H.R.; Salah, K. Blockchain-based proof of delivery of physical assets with single and multiple transporters. IEEE Access 2018, 6, 46781–46793. [Google Scholar] [CrossRef]
Account | Address |
---|---|
Farmer | 0xca35b7d915458ef540ade6068dfe2f44e8fa733c |
Intermediary | 0x14723a09acff6d2a60dcdf7aa4aff308fddc160c |
Consumer | 0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db |
Retailer | 0x583031d1113ad414f02576bd6afabfb302140225 |
OIA | 0xdd870fa1b7c4700f2bd7f44238821c26f7392148 |
Arbitrator | 0xdbc3a811ec4a57b370892cc11790d9e3d65d41cb |
© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Shih, D.-H.; Lu, K.-C.; Shih, Y.-T.; Shih, P.-Y. A Simulated Organic Vegetable Production and Marketing Environment by Using Ethereum. Electronics 2019, 8, 1341. https://doi.org/10.3390/electronics8111341
Shih D-H, Lu K-C, Shih Y-T, Shih P-Y. A Simulated Organic Vegetable Production and Marketing Environment by Using Ethereum. Electronics. 2019; 8(11):1341. https://doi.org/10.3390/electronics8111341
Chicago/Turabian StyleShih, Dong-Her, Kuan-Chu Lu, Yi-Ting Shih, and Po-Yuan Shih. 2019. "A Simulated Organic Vegetable Production and Marketing Environment by Using Ethereum" Electronics 8, no. 11: 1341. https://doi.org/10.3390/electronics8111341
APA StyleShih, D. -H., Lu, K. -C., Shih, Y. -T., & Shih, P. -Y. (2019). A Simulated Organic Vegetable Production and Marketing Environment by Using Ethereum. Electronics, 8(11), 1341. https://doi.org/10.3390/electronics8111341