李鳳陽，秦 興

（杭州電子科技大學(xué)電子信息學(xué)院，浙江杭州 310018）

受到人們生活水平不斷提高帶來的需求拉動(dòng)，養(yǎng)殖業(yè)在我國得到了快速發(fā)展，其產(chǎn)值已占我國農(nóng)業(yè)生產(chǎn)總產(chǎn)值的34%，從事養(yǎng)殖業(yè)的勞動(dòng)力超過1億人［1］。近年來，隨著互聯(lián)網(wǎng)、大數(shù)據(jù)等先進(jìn)技術(shù)的發(fā)展，養(yǎng)殖業(yè)也逐漸向?qū)I(yè)化、信息自動(dòng)化轉(zhuǎn)變。為解決肉類食品安全隱患，更是開發(fā)了一系列的肉類食品質(zhì)量安全追溯系統(tǒng)來檢測(cè)家畜健康以及防止病死家畜流入市場(chǎng)，為肉類產(chǎn)品的安全提供了有力保障［2］。但與一些發(fā)達(dá)國家相比，我國的養(yǎng)殖產(chǎn)業(yè)還存在很大的不足［3］，如我國目前缺乏完善的養(yǎng)殖交易體系以及養(yǎng)殖投資體系，使整個(gè)養(yǎng)殖交易環(huán)境存在很大的盲目性和風(fēng)險(xiǎn)不可控性。

現(xiàn)階段我國的農(nóng)業(yè)養(yǎng)殖方式仍以小規(guī)模養(yǎng)殖為主，這種養(yǎng)殖方式存在如下弊端：（1）資金短缺：養(yǎng)殖行業(yè)前期需要很高的投入資金，但很多農(nóng)戶并不能拿出這筆資金，同時(shí)又無法提供合格的抵押品進(jìn)行信貸融資［4］；（2）盲目性：大部分養(yǎng)殖者的生產(chǎn)具有很大的盲目性，對(duì)市場(chǎng)的預(yù)測(cè)及抗市場(chǎng)風(fēng)險(xiǎn)能力差；（3）缺乏信任：交易雙方只是簡(jiǎn)單的買賣關(guān)系，彼此缺乏信任，從而導(dǎo)致整個(gè)交易體系不穩(wěn)定；（4）信息不對(duì)稱：不同角色掌握的信息存在嚴(yán)重的不對(duì)稱性，為了維護(hù)自身的利益導(dǎo)致信息壁壘嚴(yán)重，進(jìn)而造成產(chǎn)供銷嚴(yán)重脫節(jié)［5］。

基于傳統(tǒng)的中心化信息技術(shù)開發(fā)的訂單交易平臺(tái)在一定程度上能夠解決上述資金短缺、盲目性等問題，但互信問題卻很難得到有效解決。區(qū)塊鏈技術(shù)的去中心化、分布式存儲(chǔ)、信息不可篡改等特點(diǎn)為解決農(nóng)業(yè)訂單互信問題提供了有力的技術(shù)支撐。

1 區(qū)塊鏈技術(shù)

區(qū)塊鏈技術(shù)源自于比特幣（Bitcoin）的底層技術(shù)，2008年，化名為“中本聰”（Satoshi Nakamoto）的學(xué)者首次提出了一種不需要中間任何金融機(jī)構(gòu)，直接由一方發(fā)起并支付給另外一方的電子貨幣交易系統(tǒng)［6-7］。隨著區(qū)塊鏈技術(shù)的發(fā)展，目前已經(jīng)出現(xiàn)很多的區(qū)塊鏈技術(shù)平臺(tái)，如2013年Buterin提出的以太坊區(qū)塊鏈平臺(tái)［8］、2014年Schwartz等提出的瑞波比［9］和Linux基金會(huì)的開源項(xiàng)目超級(jí)賬本（Hyperledger Fabric）等。區(qū)塊鏈技術(shù)的核心優(yōu)勢(shì)是去中心化，通過運(yùn)用數(shù)據(jù)加密、時(shí)間戳、共識(shí)算法和分布式存儲(chǔ)等手段，在節(jié)點(diǎn)無需互信的條件下完成點(diǎn)對(duì)點(diǎn)交易，解決了中心化機(jī)構(gòu)普遍存在的高成本、低效率和數(shù)據(jù)存儲(chǔ)不安全等問題［10］。根據(jù)用戶需求以及應(yīng)用場(chǎng)景的不同，區(qū)塊鏈又分為公有鏈、私有鏈、聯(lián)盟鏈。其中，公有鏈的去中心化程度最高，但交易速度慢、節(jié)點(diǎn)加入門檻低；私有鏈與公有鏈的特點(diǎn)完全相反，網(wǎng)絡(luò)的寫入和讀取都要受到某個(gè)組織或機(jī)構(gòu)的許可才可進(jìn)行操作；聯(lián)盟鏈介于公有鏈和私有鏈之間，實(shí)現(xiàn)部分去中心化，有多個(gè)組織共同維護(hù)區(qū)塊鏈的運(yùn)行，構(gòu)成一個(gè)利益共同體。聯(lián)盟鏈不僅交易速度快，同時(shí)又能保證數(shù)據(jù)的安全有效。

本研究平臺(tái)的搭建主要是基于Fabric底層環(huán)境。Hyperledger Fabric不同于比特幣和以太坊，它是專門針對(duì)于企業(yè)級(jí)的區(qū)塊鏈應(yīng)用而設(shè)計(jì)，并引入了成員服務(wù)［11］，是本研究平臺(tái)搭建的最好選擇。超級(jí)賬本采用模塊化架構(gòu)設(shè)計(jì)，復(fù)用通用的功能模塊和接口。模塊化的方法帶來了可擴(kuò)展性、靈活性等優(yōu)勢(shì)，會(huì)減少模塊修改、升級(jí)帶來的影響，能很好地利用微服務(wù)實(shí)現(xiàn)區(qū)塊鏈應(yīng)用系統(tǒng)的開發(fā)和部署［12-14］。其核心部分包括4個(gè)部分：身份管理、賬本管理、交易管理、智能合約。

身份管理：考慮到商業(yè)應(yīng)用對(duì)安全、隱私、性能的需求，聯(lián)盟鏈提高了準(zhǔn)入門檻，成員必須被許可才能加入網(wǎng)絡(luò)。成員管理服務(wù)通過公鑰基礎(chǔ)設(shè)施（PKI）和去中心化共識(shí)機(jī)制使得非許可的區(qū)塊鏈變成許可制的區(qū)塊鏈。

賬本管理：Fabric使用建立在HTTP/2上的P2P協(xié)議來管理分布式賬本，采用可插拔的方式來根據(jù)需求設(shè)置共識(shí)協(xié)議，如PBFT、Raft等（本研究平臺(tái)使用的是Fabric默認(rèn)的kafka共識(shí)，它提供了交易排序功能和崩潰故障容錯(cuò)的性能）。在賬本中主要包括區(qū)塊鏈和State兩塊。區(qū)塊鏈?zhǔn)且幌盗羞B在一起的區(qū)塊，用來記錄歷史交易。State對(duì)應(yīng)賬本的當(dāng)前最新狀態(tài)，它是一個(gè)key-value數(shù)據(jù)庫，F(xiàn)abric默認(rèn)采用的是Level DB。

交易管理：Fabric上的交易管理分為部署交易和調(diào)用交易。部署交易就是安裝鏈碼的過程，當(dāng)部署交易成功執(zhí)行時(shí)，鏈碼就被部署到各個(gè)peer節(jié)點(diǎn)上。調(diào)用交易是客戶端應(yīng)用程序通過Fabric提供的應(yīng)用程序接口調(diào)用先前已部署好的某個(gè)鏈碼的某個(gè)函數(shù)執(zhí)行交易，并相應(yīng)地讀取和寫入KV數(shù)據(jù)庫，返回成功或者失敗。

智能合約：Fabric的智能合約被稱為鏈碼，是采用Go、Java、Node.js編寫的一段代碼，用于處理網(wǎng)絡(luò)成員同意的業(yè)務(wù)邏輯。

2 平臺(tái)設(shè)計(jì)

2.1 系統(tǒng)整體功能分析

基于區(qū)塊鏈的農(nóng)業(yè)訂單交易平臺(tái)實(shí)現(xiàn)的功能是訂單交易以及訂單參養(yǎng)2項(xiàng)業(yè)務(wù)。參與人員主要分為3類：訂單方、基地方、參養(yǎng)方。訂單方為生豬收購方，他們根據(jù)自己的需求下發(fā)訂單到該平臺(tái)；基地方為線下運(yùn)營方，提供傳統(tǒng)養(yǎng)殖中、小、微企業(yè)及個(gè)人養(yǎng)殖場(chǎng)地，主要以租賃合作方式為主，劃分虛擬經(jīng)營權(quán)，實(shí)現(xiàn)共同經(jīng)營?；胤娇稍谠撈脚_(tái)看到所有訂單方下發(fā)的訂單，然后根據(jù)自己基地的大小接收合適的訂單。同時(shí)在接收訂單后，再按養(yǎng)殖基地的規(guī)模分配訂單給養(yǎng)殖合作方；參養(yǎng)方是指投資者，可根據(jù)基地方發(fā)布的參養(yǎng)訂單信息選擇自己想要參養(yǎng)的產(chǎn)品，提供養(yǎng)殖成本，分享養(yǎng)殖收益。整個(gè)訂單交易流程如圖1所示。

2.2 系統(tǒng)整體架構(gòu)設(shè)計(jì)

農(nóng)業(yè)訂單交易平臺(tái)的整體架構(gòu)可分為應(yīng)用層、網(wǎng)絡(luò)層和存儲(chǔ)層。其中，在應(yīng)用層和網(wǎng)絡(luò)層中間還包含1個(gè)合約層，由于合約層主要是對(duì)業(yè)務(wù)邏輯的實(shí)現(xiàn)，因此將其與網(wǎng)絡(luò)層一起介紹。整體架構(gòu)如圖2所示。

應(yīng)用層封裝了整個(gè)訂單交易的應(yīng)用場(chǎng)景，是用戶與信息平臺(tái)交互的媒介。應(yīng)用層是通過Spring MVC框架和HTML標(biāo)志語言來開發(fā)前端頁面，通過ajax來完成數(shù)據(jù)的交互。本研究的平臺(tái)主要是在Linux操作系統(tǒng)下搭建開發(fā)環(huán)境，使用Java語言在Eclipse集成開發(fā)工具下進(jìn)行系統(tǒng)開發(fā)，采用Apache公司的tomcat應(yīng)用服務(wù)器。同時(shí)，在應(yīng)用層接入了本地?cái)?shù)據(jù)庫，該數(shù)據(jù)庫采用的是MySQL數(shù)據(jù)庫，采用該數(shù)據(jù)庫是為了使用戶能快速查詢到自己想要查詢的信息，該數(shù)據(jù)庫的信息并非人為寫入，而是從區(qū)塊鏈中動(dòng)態(tài)獲取的。數(shù)據(jù)庫在用戶登錄或指定時(shí)間內(nèi)都會(huì)對(duì)數(shù)據(jù)進(jìn)行動(dòng)態(tài)更新，將底層數(shù)據(jù)庫中的數(shù)據(jù)導(dǎo)入到本地的MySQL數(shù)據(jù)庫中?？杀苊馊藶閷懭氤霈F(xiàn)的造假情況，從而保證了數(shù)據(jù)的安全性，同時(shí)也解決了用戶從區(qū)塊鏈中讀取數(shù)據(jù)時(shí)間久的問題，提供了更好的用戶使用環(huán)境。

網(wǎng)絡(luò)層介于應(yīng)用層和存儲(chǔ)層之間，是整個(gè)平臺(tái)的核心部分。主要是接收應(yīng)用層發(fā)來的操作請(qǐng)求，然后通過fabricjava-sdk接口調(diào)用由Go語言編寫的鏈碼來完成業(yè)務(wù)操作。若發(fā)來的請(qǐng)求是存儲(chǔ)合約則將合約內(nèi)容打包成區(qū)塊傳入數(shù)據(jù)層進(jìn)行存儲(chǔ)，若發(fā)來的是查詢操作，則通過fabric-java-sdk的查詢操作從數(shù)據(jù)庫讀取數(shù)據(jù)并返回給應(yīng)用層。

存儲(chǔ)層用來存儲(chǔ)數(shù)據(jù)，每個(gè)節(jié)點(diǎn)維護(hù)一個(gè)賬本，賬本的內(nèi)容全都是一致的。存儲(chǔ)層主要采用的是levelDB數(shù)據(jù)庫，每個(gè)區(qū)塊包含區(qū)塊頭和區(qū)塊體2個(gè)部分。區(qū)塊頭封裝了前一區(qū)塊的hash、目標(biāo)hash、時(shí)間戳以及Merkle根。目標(biāo)hash的實(shí)現(xiàn)代碼如下：

Hex.encode Hex String（SDKUtils.calculate Block Hash（client，block InfoTest.get Block Number（），block InfoTest.get Previous Hash（），blockInfoTest.get Data Hash（）））

此外，腸道微生物的生長環(huán)境與胃腸黏膜聯(lián)系密切，與腸上皮細(xì)胞緊密相連，并對(duì)胃腸黏膜的生理功能有一定的調(diào)節(jié)作用?；啬c末端和結(jié)腸的L細(xì)胞在特定營養(yǎng)物和消化產(chǎn)物的誘導(dǎo)下分泌PYY和GLP-1[63-64]。L細(xì)胞也受腸道微生物發(fā)酵產(chǎn)生的短鏈脂肪酸(乙酸、丁酸、丙酸)的影響，提高血漿PYY和GLP-1的水平[65]。L細(xì)胞釋放的PYY和GLP-1不僅抑制胃運(yùn)動(dòng)，改善葡萄糖穩(wěn)態(tài)，還引起飽腹感和行為改變。

其中，blockInfoTest.get Block Number（）為獲取區(qū)塊高度，block InfoTest.get Previous Hash（）為獲取前一區(qū)塊的hash值，block InfoTest.get Data Hash（）為獲取的Merkle根（即該區(qū)塊中全部合約內(nèi)容生成的hash值）。目標(biāo)函數(shù)是由當(dāng)前區(qū)塊高度、前一區(qū)塊hash以及合約hash再次經(jīng)過一定的hash計(jì)算獲得的。

2.3 系統(tǒng)功能模塊的設(shè)計(jì)與代碼實(shí)現(xiàn)

整個(gè)系統(tǒng)實(shí)現(xiàn)的功能主要包括用戶的注冊(cè)/登錄、合約存儲(chǔ)和信息查詢，具體功能模塊如圖3所示。

2.3.1 用戶注冊(cè)和登錄模塊 用戶注冊(cè)：根據(jù)角色的不同選取不同的注冊(cè)頁面，主要包括訂單方注冊(cè)、基地方注冊(cè)和參養(yǎng)方注冊(cè)。訂單方注冊(cè)包括賬號(hào)、密碼、訂單方名稱、負(fù)責(zé)人姓名、負(fù)責(zé)人電話、公司法人姓名、法人身份證號(hào)、法人手機(jī)號(hào)碼、手機(jī)驗(yàn)證碼以及上傳身份證照片和公司營業(yè)執(zhí)照，以上信息均為必填項(xiàng)，并在文本框中提醒為必填項(xiàng)，將相應(yīng)信息存入到訂單方數(shù)據(jù)庫表中。基地方注冊(cè)包括賬號(hào)、密碼、基地名稱、基地地址、公司法人姓名、法人身份證號(hào)、法人手機(jī)號(hào)碼、手機(jī)驗(yàn)證碼、基地服務(wù)內(nèi)容、服務(wù)周期以及上傳法人身份證照與營業(yè)執(zhí)照照片、基地logo等，以上信息均為必填項(xiàng)，在文本框中提醒為必填項(xiàng)，并將對(duì)應(yīng)的信息存入到基地方數(shù)據(jù)庫表中。參養(yǎng)方注冊(cè)包括賬號(hào)、密碼、手機(jī)號(hào)碼、手機(jī)驗(yàn)證碼，以上信息均為必填項(xiàng)，在文本框中提示為必填項(xiàng)，并將相應(yīng)信息存儲(chǔ)到參養(yǎng)方數(shù)據(jù)庫表中。參養(yǎng)方注冊(cè)流程圖如圖4所示。訂單方用戶注冊(cè)頁面如圖5所示。

用戶注冊(cè)信息存儲(chǔ)執(zhí)行的mysql語句如下所示：

INSERT INTO cyf（name，password，phone）VALUES（“張三”，“123456”，“13356776533”）。

用戶登錄：用戶在登錄過程中不需要選取角色，只需要輸入用戶名和密碼進(jìn)行登錄。用戶的登錄過程實(shí)質(zhì)上是數(shù)據(jù)查詢的過程，用戶輸入用戶名和密碼后，會(huì)從3個(gè)數(shù)據(jù)庫表中進(jìn)行查詢，若查找到相同的用戶名和密碼，根據(jù)查找到數(shù)據(jù)的數(shù)據(jù)庫表名稱，頁面從登錄界面跳轉(zhuǎn)到對(duì)應(yīng)的用戶操作界面。

用戶登錄執(zhí)行的mysql語句：

SELECT COUNT（*）d FROM ddf WHERE name＝“張三”AND password＝“123456”；

基地方數(shù)據(jù)表查詢：

SELECTCOUNT（*）j FROM jdfWHERE name＝“張三”AND password＝“123456”；

參養(yǎng)方數(shù)據(jù)表查詢：

SELECT COUNT（*）c FROM ccf WHERE name＝“張三”AND password＝“123456”；

2.3.2 合約存儲(chǔ)模塊 該模塊的設(shè)計(jì)服務(wù)對(duì)象包括訂單方、基地方和參養(yǎng)方。當(dāng)基地方認(rèn)購了訂單方的訂單并經(jīng)過訂單方確認(rèn)訂單合同后，合同信息會(huì)進(jìn)行上鏈存儲(chǔ)。訂單認(rèn)購成功后，參養(yǎng)方可對(duì)訂單進(jìn)行參養(yǎng)，參養(yǎng)合同也將進(jìn)行上鏈存儲(chǔ)。在合同正式存儲(chǔ)之前，首先對(duì)合約ID進(jìn)行查詢，確保合約不被重復(fù)上鏈。合同內(nèi)容以json格式存儲(chǔ)。

合約存儲(chǔ)在Fabric-java-sdk中定義的接口，如下所示：

鏈碼中實(shí)現(xiàn)合同存儲(chǔ)的部分代碼如下：

2.3.3 信息查詢模塊 信息查詢可通過區(qū)塊查詢和合約查詢，區(qū)塊的查詢方式又可分為hash查詢以及查詢?nèi)繀^(qū)塊。hash查詢是通過輸入指定的hash獲取指定的區(qū)塊信息。全部區(qū)塊查詢則是不輸入任何hash值直接進(jìn)行區(qū)塊查詢。合同信息的查詢可通過ID獲取指定訂單的合同信息，也可根據(jù)用戶名或用戶身份獲取該用戶下全部的訂單合同。

Fabric-java-sdk中代碼的實(shí)現(xiàn)：

3 系統(tǒng)測(cè)試與分析

系統(tǒng)測(cè)試的目的是檢測(cè)系統(tǒng)的實(shí)際操作流程是否與系統(tǒng)設(shè)計(jì)的流程相一致，以及是否完成用戶要求的全部功能。系統(tǒng)測(cè)試環(huán)境如表1所示。

表1 系統(tǒng)測(cè)試環(huán)境

3.1 登錄模塊測(cè)試

具體如表2所示。

3.2 平臺(tái)訂單發(fā)布及認(rèn)購測(cè)試

訂單的發(fā)布以及認(rèn)購：訂單方在登錄賬號(hào)后，可在發(fā)布界面發(fā)布訂單（圖6-a），點(diǎn)擊保存后，訂單發(fā)布成功。此時(shí)基地方登錄賬號(hào)后，在訂單界面可看到所有訂單方發(fā)布的所有訂單（圖6-b），可點(diǎn)擊認(rèn)購按鈕進(jìn)行訂單認(rèn)購。在訂單方確認(rèn)后，則合同開始上鏈，此時(shí)查詢訂單可看到圖6-c所示情況，提示上鏈中和上鏈成功，經(jīng)測(cè)試可知合同上鏈時(shí)間在1 min內(nèi)，從而大大節(jié)約了用戶的等待時(shí)間，有更好的用戶體驗(yàn)。參養(yǎng)過程和訂單認(rèn)購過程相似，因此不再贅述。同時(shí)，視頻監(jiān)控的引入讓訂單方和參養(yǎng)方能及時(shí)了解產(chǎn)品的養(yǎng)殖情況，只需在首頁或我的訂單中點(diǎn)擊查看詳情。

表2 登錄測(cè)試

除此之外，還使用白盒測(cè)試方法，使用Junit測(cè)試工具對(duì)各模塊代碼進(jìn)行測(cè)試，確保每個(gè)模塊的代碼都能達(dá)到預(yù)期結(jié)果。經(jīng)過測(cè)試可知，合同上鏈速度維持在1 min以內(nèi)，這有效節(jié)約了用戶的等待時(shí)間，為使用戶有更好的體驗(yàn)，平臺(tái)引入了本地的MySQL數(shù)據(jù)庫，該數(shù)據(jù)庫的數(shù)據(jù)是在用戶登錄賬號(hào)或一定時(shí)間段內(nèi)動(dòng)態(tài)地從區(qū)塊鏈中更新進(jìn)去的，因此用戶查詢時(shí)，無需再從區(qū)塊鏈中進(jìn)行查詢，大大節(jié)約了用戶時(shí)間，同時(shí)，由于數(shù)據(jù)并非人為寫入，充分保證數(shù)據(jù)的安全可靠。

本平臺(tái)的開發(fā)是在分析了國內(nèi)外當(dāng)前的養(yǎng)殖交易模式的基礎(chǔ)上，依據(jù)我國市場(chǎng)需求提出的一種新的養(yǎng)殖交易理念。該平臺(tái)的開發(fā)，為養(yǎng)殖者提供了一個(gè)安全、可靠的銷售渠道，同時(shí)也為收購者提供一個(gè)長期、穩(wěn)定的進(jìn)貨來源，更是為小規(guī)模投資提供了可能。區(qū)塊鏈技術(shù)的應(yīng)用，有效保證了身份信息、銷售信息的準(zhǔn)確性和可靠性，解決了陌生人之間的互信問題，也將養(yǎng)殖者、銷售者和投資者緊密聯(lián)系起來，構(gòu)成一個(gè)利益共同體。除此之外，本平臺(tái)還引入了視頻監(jiān)控系統(tǒng)，每個(gè)加入進(jìn)來的養(yǎng)殖基地都會(huì)安裝監(jiān)控設(shè)備，并將實(shí)時(shí)監(jiān)控視頻上傳到該平臺(tái)，每個(gè)訂單下發(fā)者和參養(yǎng)者都可在登錄賬號(hào)后，選擇訂單列表中訂單詳情進(jìn)行視頻查看，以便更好地掌握生豬的養(yǎng)殖情況以及養(yǎng)殖環(huán)境。

4 結(jié)束語

區(qū)塊鏈技術(shù)作為近年來最火的數(shù)據(jù)存儲(chǔ)底層技術(shù)，改變了多年來中心化管理和交易的局面。本研究主要分析了農(nóng)業(yè)訂單的交易過程，結(jié)合區(qū)塊鏈技術(shù)，給出了一套基于區(qū)塊鏈技術(shù)的農(nóng)業(yè)訂單平臺(tái)建設(shè)方案。該平臺(tái)利用區(qū)塊鏈技術(shù)的去中心化和不可篡改的特性，解決了訂單協(xié)議的消息不對(duì)稱、信息安全和互信等問題。同時(shí)區(qū)塊鏈技術(shù)也可用于食品追溯和解決食品安全問題。區(qū)塊鏈技術(shù)的引用將會(huì)為農(nóng)產(chǎn)品市場(chǎng)打開一個(gè)全新的局面。