王華建，黎人瑋，周 寰，陽(yáng)國(guó)貴

國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院，湖南 長(zhǎng)沙 410073

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，外包行為逐漸進(jìn)化為任務(wù)發(fā)起方（發(fā)包者）將其自身不能解決的問(wèn)題以自由自愿的形式公布到互聯(lián)網(wǎng)平臺(tái)（中介機(jī)構(gòu)），進(jìn)而傳遞到非特定大眾的新形式。該形式下的任務(wù)通常由個(gè)人承擔(dān)，且涉及到多個(gè)承擔(dān)人個(gè)體（接包者）。這種一對(duì)多的外包形式可定義為眾包[1]。

眾包是一種分布式解決問(wèn)題的機(jī)制，也是一種新興的商業(yè)模式。目前，已涌現(xiàn)出UPWork、Freelancer、Amazon Mechanical Turk 等一批規(guī)模較大且高度標(biāo)準(zhǔn)化的眾包平臺(tái)。這些平臺(tái)各有特點(diǎn)，但都遵循相同的交付流程，由于涉及到報(bào)酬的交付，在實(shí)際操作中面臨許多信譽(yù)問(wèn)題，主要集中在以下三方面：1）缺乏有效的接包者篩選和結(jié)果提交機(jī)制；2）缺乏有效的合約執(zhí)行狀況監(jiān)管機(jī)制；3）缺乏全過(guò)程自動(dòng)化支持。

總的來(lái)說(shuō)，眾包活動(dòng)中多方利益保護(hù)的核心矛盾在于：如何在開(kāi)放的互聯(lián)網(wǎng)環(huán)境下建立接包者和發(fā)包者對(duì)于平臺(tái)的多方信任，以提高眾包任務(wù)的完成質(zhì)量。對(duì)于發(fā)包者，需要保證其任務(wù)得到有效完成而不被特定接包者群體串謀騙取薪酬；對(duì)于接包者，需要保證其結(jié)果數(shù)據(jù)不被其他接包者輕易竊取，并能獲得相應(yīng)薪酬。

區(qū)塊鏈技術(shù)[2]和智能合約[3]技術(shù)為眾包活動(dòng)的權(quán)益保護(hù)提供了新的解決思路。本文旨在利用區(qū)塊鏈技術(shù)和共識(shí)算法[4]在確認(rèn)權(quán)利、保存證據(jù)和可追溯性方面的優(yōu)勢(shì)，設(shè)計(jì)一種安全、公平、可靠的基于智能合約的眾包活動(dòng)全過(guò)程監(jiān)控方法和系統(tǒng)。具體而言，首先結(jié)合智能合約和承諾機(jī)制[5]為眾包系統(tǒng)設(shè)計(jì)一種兩階段提交機(jī)制，保障了數(shù)據(jù)隱私，提高了結(jié)果數(shù)據(jù)的質(zhì)量，消除了隨機(jī)欺詐和抄襲現(xiàn)象；然后基于承諾方案進(jìn)一步設(shè)計(jì)了一種無(wú)偏隨機(jī)選擇算法，以保證任務(wù)分配的公平、公開(kāi)、透明和可信度；最后，實(shí)現(xiàn)了基于以太坊公共測(cè)試網(wǎng)絡(luò)Ropsten 的系統(tǒng)，以驗(yàn)證整體方案的可行性。

1 總體方案設(shè)計(jì)

本方案中涉及4 種實(shí)體角色：普通用戶(hù)、發(fā)包者R、接包者W和接包者委員會(huì)C。本節(jié)將介紹本方案的整體系統(tǒng)架構(gòu)和眾包任務(wù)周期。

本方案由4 個(gè)基于區(qū)塊鏈的智能合約實(shí)現(xiàn)：用戶(hù)管理（user management,UM）合約、眾包（crowd-sourcing,CS）合約、眾包管理（crowd-sourcing management,CSM）合約、兩階段提交（two-phase submission,TPS）合約。其中：用戶(hù)只要在UM 和CS 中操作即可，而TPS和CSM 能為眾包參與者提供相關(guān)接口。參與系統(tǒng)的接包者越多，系統(tǒng)就越可靠，越可信。圖1給出了本方案的總體設(shè)計(jì)架構(gòu)和整體流程。

為了便于理解本方案，可將整個(gè)眾包活動(dòng)分為兩部分：任務(wù)創(chuàng)建和任務(wù)執(zhí)行。前者包括任務(wù)設(shè)置、接包者登記、無(wú)偏隨機(jī)選擇、接包者反饋、任務(wù)分配等，如圖1中的步驟①～③所示。

在任務(wù)創(chuàng)建階段，R首先使用UM 生成CS。發(fā)布任務(wù)之前，發(fā)包者R應(yīng)該仔細(xì)考慮眾包任務(wù)的詳細(xì)條款，尤其是委員會(huì)成員數(shù)量N。接包者越多，眾包結(jié)果越可信，但需要支付更多的報(bào)酬。發(fā)布任務(wù)之后，在線(xiàn)的W可以閱讀合約中的任務(wù)介紹，然后根據(jù)自己的情況決定是否報(bào)名參加眾包任務(wù)。當(dāng)報(bào)名時(shí)間結(jié)束或報(bào)名人數(shù)達(dá)到一定數(shù)量時(shí)，可使用無(wú)偏隨機(jī)選擇算法選擇N個(gè)獨(dú)立的接包者組成C。挑選過(guò)程由UM 和TPS 共同實(shí)施，一旦被選擇，W就可以在一個(gè)時(shí)間窗口內(nèi)選擇接受或拒絕。W在接受任務(wù)時(shí)需要支付一筆承諾費(fèi)用，拒絕接受任務(wù)或沒(méi)有反饋都會(huì)受到懲罰。

若成功接受任務(wù)的接包者數(shù)量達(dá)到預(yù)定要求，則C組建成功，系統(tǒng)進(jìn)入任務(wù)執(zhí)行階段，包括結(jié)果提交、質(zhì)量評(píng)價(jià)、質(zhì)量獎(jiǎng)勵(lì)等，如圖1中的步驟④～⑥所示。R啟動(dòng)任務(wù)時(shí)需要發(fā)布任務(wù)的細(xì)節(jié)，并支付可能的最大獎(jiǎng)勵(lì)。任務(wù)開(kāi)始后，接包者W獨(dú)立在鏈下完成任務(wù)并生成結(jié)果，然后將結(jié)果不加篡改地提交給TPS。任務(wù)提交時(shí)間結(jié)束后，由R檢測(cè)W提交狀態(tài)。在這一環(huán)節(jié)中，未能按時(shí)提交承諾和結(jié)果的接包者將受到懲罰。若沒(méi)有接包者成功提交結(jié)果，則表明任務(wù)失敗，C將被解散。完成任務(wù)的R和W可以收回獎(jiǎng)勵(lì)和承諾費(fèi)。注意，R只能在所有W都取款后才能取出剩余的押金。

圖1 去中心化的眾包平臺(tái)設(shè)計(jì)架構(gòu)和整體流程Figure 1 Decentralized crowdsourcing platform design architecture and overall flow

2 前后端關(guān)鍵方法

本方案主要基于區(qū)塊鏈智能合約來(lái)實(shí)現(xiàn)，雖然沒(méi)有中心化的第三方平臺(tái)運(yùn)行整個(gè)框架，但同樣可以分為前端和后端來(lái)實(shí)現(xiàn)。其中，后端依托于運(yùn)行在區(qū)塊鏈網(wǎng)絡(luò)中的智能合約，前端則通過(guò)瀏覽器訪(fǎng)問(wèn)可視化界面，簡(jiǎn)化用戶(hù)調(diào)用智能合約接口的難度。

2.1 后端關(guān)鍵技術(shù)

在本方案的設(shè)計(jì)中，后端主要是基于區(qū)塊鏈智能合約實(shí)現(xiàn)的，采用了一些關(guān)鍵技術(shù)來(lái)保證發(fā)包者的數(shù)據(jù)隱私和接包者之間的信息獨(dú)立性，并且可以自動(dòng)檢查眾包任務(wù)的質(zhì)量。首先，本文提出了一種兩階段提交機(jī)制，以保證用戶(hù)信息和提交結(jié)果的隱私；然后提出了一種無(wú)偏隨機(jī)選擇算法，以保證接包者委員會(huì)的選擇具有隨機(jī)性和獨(dú)立性。

2.1.1 兩階段提交機(jī)制

在本方案中，基于承諾的兩階段提交方案是確保接包者相互獨(dú)立、互不串謀的關(guān)鍵技術(shù)，也是提交任務(wù)結(jié)果數(shù)據(jù)時(shí)避免接包者互相抄襲的重要手段。兩階段提交機(jī)制在第1 階段通過(guò)加密信息確保任何W并不知曉其他接包者的真實(shí)信息，在第2 階段使信息公開(kāi)，確保每個(gè)接包者提交的信息是誠(chéng)實(shí)且不能篡改的。圖2顯示了基于承諾方案的兩階段提交機(jī)制。

圖2 基于承諾方案的兩階段提交機(jī)制Figure 2 Two-phase commit mechanism based on commitment scheme

第1 個(gè)階段是存證提交階段，屬于預(yù)提交。每個(gè)接包者提交自己的結(jié)果Pk，其內(nèi)容是結(jié)果數(shù)據(jù)加隨機(jī)數(shù)據(jù)的哈希值，即Pk=Hash(sk,mk)。秘密隨機(jī)值sk是由wk自己生成的。在此期間，sk的值是保密的，以防止其他接包者根據(jù)sk推斷出任務(wù)結(jié)果。此外，如果兩個(gè)不同的接包者提交了相同的結(jié)果，TPS 就會(huì)將這種情況歸類(lèi)為剽竊。后提交的承諾將被拒絕，該接包者必須重新選擇sk生成新的承諾。由于sk的隨機(jī)性和隱私性，在接包者Wk提交承諾Pk后，其他接包者Wo即使得到Pk也不能獲取相應(yīng)的mk，從而保證了結(jié)果數(shù)據(jù)的安全性。在這個(gè)階段，接包者僅憑承諾內(nèi)容無(wú)法知曉除了自己結(jié)果外的其他詳細(xì)結(jié)果，卻可以確保其他人都不可篡改地完成他們各自的工作。

第2 階段是驗(yàn)證提交階段，屬于正式提交。接包者可以將原始結(jié)果和隨機(jī)數(shù)值上傳到TPS。在這個(gè)階段，TPS 將判斷mk、sk、Pk的值是否滿(mǎn)足Hash(sk,mk)=Pk。只有滿(mǎn)足這個(gè)公式的結(jié)果數(shù)據(jù)才會(huì)被合約接受，這樣就保證了接包者在承諾階段無(wú)法修改提交的結(jié)果數(shù)據(jù)，否則驗(yàn)證將失敗，從而消除了作弊的可能性。

2.1.2 無(wú)偏隨機(jī)選取

無(wú)偏隨機(jī)地為委員會(huì)挑選接包者是至關(guān)重要的。無(wú)偏性強(qiáng)調(diào)的是任何人在選擇委員會(huì)時(shí)都不會(huì)有優(yōu)勢(shì)，而隨機(jī)性則是指被選擇的接包者不能串通一氣。如果要求接包者在報(bào)名時(shí)提交一定的注冊(cè)費(fèi)，就可以在一定程度上避免女巫攻擊的可能性?；?.1.1 中描述的兩階段提交方案，本文在文獻(xiàn)[6]中選擇算法的基礎(chǔ)上提出了新的無(wú)偏隨機(jī)選人算法。在該算法中，各方先通過(guò)兩階段報(bào)名機(jī)制提交私密的隨機(jī)數(shù)，再由智能合約進(jìn)行無(wú)偏隨機(jī)選人。算法細(xì)節(jié)如算法1 所示。

在兩階段提交機(jī)制的支持下，接包者提交Hash(Rk)。該數(shù)為預(yù)報(bào)名階段的一個(gè)隨機(jī)數(shù)哈希，可以與其他接包者提交的數(shù)據(jù)相同，即每個(gè)人只需提交自己的數(shù)據(jù)，而不必關(guān)心是否與他人提交的數(shù)據(jù)相同。原始隨機(jī)數(shù)將在正式報(bào)名階段公布。在確定Rk滿(mǎn)足承諾后，TPS 將在選擇算法中保存Rk，并將其作為隨機(jī)種子的一個(gè)組成部分。接包者只有在成功注冊(cè)后才能進(jìn)入Wselected。此外，還要注意以下幾點(diǎn)：

1）R也要參與報(bào)名，因?yàn)樗残枰峁┮欢ǖ碾S機(jī)性。

2）每個(gè)報(bào)名者只能提供一個(gè)隨機(jī)數(shù)，若在第1 階段多次提交，則TPS 只保留最新的一個(gè)隨機(jī)數(shù)。

3）接包者正式報(bào)名時(shí)需要支付報(bào)名費(fèi)，以防止惡意R或機(jī)構(gòu)發(fā)起女巫攻擊。

4）以非對(duì)稱(chēng)加密的方式來(lái)分配任務(wù)。考慮到每個(gè)接包者的子任務(wù)各不相同，發(fā)包者會(huì)以對(duì)應(yīng)的公鑰加密他們的子任務(wù)。接包者收到子任務(wù)后用私鑰解密，以獲得子任務(wù)的內(nèi)容，從而避免接包者互相知曉對(duì)方的工作內(nèi)容，確保每個(gè)接包者工作的獨(dú)立性。這樣設(shè)計(jì)既可以有效防止接包者之間的抄襲，又能保護(hù)發(fā)包者的數(shù)據(jù)隱私。

算法1無(wú)偏隨機(jī)選人算法

2.2 前端設(shè)計(jì)

為了便于使用，本文設(shè)計(jì)更人性化的前端界面，如各種角色的注冊(cè)、登錄及使用，并能在后端與智能合約更好地配合，實(shí)現(xiàn)與區(qū)塊鏈的數(shù)據(jù)交互。

2.2.1 登錄和注冊(cè)

去中心化服務(wù)沒(méi)有服務(wù)器和數(shù)據(jù)庫(kù)，故難以使用傳統(tǒng)的賬號(hào)密碼登錄。平臺(tái)以區(qū)塊鏈錢(qián)包登錄的方式進(jìn)行用戶(hù)的注冊(cè)和登錄，如瀏覽器插件Metamask 等。用戶(hù)在訪(fǎng)問(wèn)界面時(shí)讀取瀏覽器上區(qū)塊鏈錢(qián)包的信息以確定身份，如圖3所示。

圖3 用戶(hù)操作示意圖Figure 3 User operation schematic diagram

用戶(hù)在本地運(yùn)行代碼后加入?yún)^(qū)塊鏈網(wǎng)絡(luò)，再通過(guò)瀏覽器訪(fǎng)問(wèn)頁(yè)面。在頁(yè)面中用戶(hù)可以選擇自己的區(qū)塊鏈錢(qián)包進(jìn)行登錄，系統(tǒng)會(huì)識(shí)別該用戶(hù)是否已經(jīng)注冊(cè)；未注冊(cè)的用戶(hù)可以選擇在智能合約UM 中進(jìn)行注冊(cè)，獲得初始信用值后加入系統(tǒng)。

2.2.2 前后端功能配合

平臺(tái)的后端主要由各種智能合約組成。用戶(hù)在前端頁(yè)面的各種操作會(huì)調(diào)用智能合約的各個(gè)接口，實(shí)現(xiàn)各種不同的功能。智能合約的使用能保證數(shù)據(jù)的可靠性和安全性，同時(shí)也能提升效率，降低成本。

數(shù)據(jù)存儲(chǔ)在區(qū)塊鏈上，用戶(hù)可以使用前端界面讀取區(qū)塊鏈上的數(shù)據(jù)，同時(shí)也可以向區(qū)塊鏈上傳數(shù)據(jù)。同樣地，智能合約也從區(qū)塊鏈上讀取數(shù)據(jù)進(jìn)行后端計(jì)算，再將計(jì)算結(jié)果上傳到區(qū)塊鏈。使用區(qū)塊鏈存儲(chǔ)數(shù)據(jù)能夠保證所有用戶(hù)數(shù)據(jù)的一致性，避免惡意篡改的現(xiàn)象發(fā)生。

在區(qū)塊鏈和智能合約主導(dǎo)的系統(tǒng)中，所有的數(shù)據(jù)和服務(wù)都由全部用戶(hù)共同提供。每個(gè)人既是客戶(hù)端又是服務(wù)端，只要有了平臺(tái)的代碼，就可以在任何一臺(tái)電腦上操作。

如圖4所示，整個(gè)平臺(tái)可以分為4 個(gè)模塊，自頂向下分別為前端、Web3.js、智能合約和以太坊，包含用戶(hù)注冊(cè)、眾包報(bào)名、無(wú)偏選人、提交數(shù)據(jù)、質(zhì)量檢測(cè)等業(yè)務(wù)功能。圖中列舉了部分業(yè)務(wù)功能，其中“接受/拒絕”“提交數(shù)據(jù)”只允許發(fā)包者操作，“無(wú)偏選人”“質(zhì)量檢測(cè)”只允許接包者進(jìn)行操作，而“用戶(hù)注冊(cè)”“眾包報(bào)名”是接包者和發(fā)包者都需要進(jìn)行的操作。Web3.js是一個(gè)JavaScript 的API 庫(kù)，可以提供Web3 對(duì)象，其中Web3.eth 是專(zhuān)門(mén)與以太坊區(qū)塊鏈交互的eth 對(duì)象，打通了前端操作和智能合約，能使去中心化應(yīng)用在以太坊上運(yùn)行。智能合約上每一筆成功的交易都會(huì)保存至底層的區(qū)塊鏈平臺(tái)，若用戶(hù)操作不當(dāng)造成交易失敗也會(huì)返回提示信息。

圖4 平臺(tái)交互示意圖Figure 4 Platform interaction diagram

2.2.3 任務(wù)流程

以標(biāo)注圖像的工作為例，發(fā)包者發(fā)布任務(wù)并進(jìn)行任務(wù)描述時(shí)需要提供含有所需標(biāo)注圖像的網(wǎng)址，其余用戶(hù)選擇參加并進(jìn)行報(bào)名。發(fā)包者可以看到報(bào)名人數(shù)并選擇提前結(jié)束報(bào)名。

在正式報(bào)名階段，發(fā)包者和接包者都輸入并提交一個(gè)隨機(jī)數(shù)進(jìn)行選舉，接包者需要使用區(qū)塊鏈錢(qián)包支付保證金。平臺(tái)根據(jù)算法1 選出接包者委員會(huì)，為每個(gè)接包者分配所需標(biāo)注的圖像。每個(gè)接包者需要標(biāo)注不同的圖像，且每幅圖像可以被多個(gè)不同的接包者標(biāo)注。

接包者根據(jù)發(fā)包者發(fā)出的網(wǎng)站完成自身任務(wù)，到達(dá)提交時(shí)間后提交自己的結(jié)果。對(duì)于一幅圖像，系統(tǒng)會(huì)以多數(shù)人提供的答案作為正確答案進(jìn)行評(píng)判，然后根據(jù)每位接包者的結(jié)果進(jìn)行報(bào)酬和信用的獎(jiǎng)懲。

2.3 威脅者模型

本文分析了接包者和發(fā)包者在眾包過(guò)程中可能存在的惡意行為，給出了幾種典型的威脅者模型，并通過(guò)信譽(yù)和押金機(jī)制規(guī)范參與者的行為。

2.3.1 發(fā)包者威脅模型

2.3.1.1 女巫攻擊

發(fā)包者或者惡意機(jī)構(gòu)可以利用多個(gè)地址在系統(tǒng)中報(bào)名的方式發(fā)動(dòng)女巫攻擊，以操控眾包結(jié)果，獲取獎(jiǎng)勵(lì)。因此，報(bào)名者正式報(bào)名時(shí)會(huì)支付一筆在眾包流程結(jié)束后可以返還的報(bào)名費(fèi)。這筆報(bào)名費(fèi)對(duì)正常參與者來(lái)說(shuō)代價(jià)很小，但是對(duì)惡意方來(lái)說(shuō)，大量的惡意賬戶(hù)同時(shí)提交報(bào)名費(fèi)將會(huì)是一筆較大的開(kāi)支。

2.3.1.2 慵懶發(fā)包者

區(qū)塊鏈上的智能合約無(wú)法自行運(yùn)行，其狀態(tài)轉(zhuǎn)換必須由某些接口觸發(fā)，并且接口執(zhí)行會(huì)花費(fèi)一些成本。如果不對(duì)發(fā)包者的行為進(jìn)行檢測(cè)，就可能出現(xiàn)行政不作為的發(fā)包者甚至出現(xiàn)惡意發(fā)包者騙取接包者信息的情況。因此，平臺(tái)設(shè)計(jì)最大的受益角色來(lái)修改狀態(tài)，因?yàn)樗麄冇袆?dòng)力執(zhí)行狀態(tài)轉(zhuǎn)換。發(fā)包者有推進(jìn)眾包活動(dòng)順利進(jìn)行的義務(wù)，必須在規(guī)定時(shí)間內(nèi)進(jìn)行指定操作。這些時(shí)間信息在眾包任務(wù)開(kāi)始前就告知接包者。

2.3.2 接包者威脅模型

2.3.2.1 騙取信息

發(fā)包者發(fā)布的任務(wù)很多時(shí)候涉及自己的知識(shí)產(chǎn)權(quán)，包含的數(shù)據(jù)通常較為敏感。這些敏感數(shù)據(jù)對(duì)發(fā)包者來(lái)說(shuō)是有價(jià)值的，因此發(fā)包者并不希望自己的數(shù)據(jù)被競(jìng)爭(zhēng)對(duì)手或者接包者竊取。為解決這個(gè)問(wèn)題，主要采取了兩點(diǎn)措施：1）在發(fā)放每個(gè)接包者的任務(wù)時(shí)采用非對(duì)稱(chēng)加密的方式，以確保每個(gè)接包者只拿到部分任務(wù)信息，避免發(fā)包者信息泄露。2）如果不對(duì)接包者進(jìn)行約束，很有可能出現(xiàn)某些接包者只是為了竊取發(fā)包者的信息而接受任務(wù)的現(xiàn)象，而這些惡意接包者并不在意一次任務(wù)失敗所造成的信譽(yù)值損失。因此，接包者接受任務(wù)時(shí)應(yīng)提交一份承諾費(fèi)，若如實(shí)完成工作，則承諾費(fèi)可以返還；若在提交過(guò)程發(fā)生惡意行為，則承諾費(fèi)將被扣除。

2.3.2.2 超時(shí)未反饋

除了發(fā)包者的慵懶行為之外，接包者也有可能出現(xiàn)超時(shí)未反饋的情況。接包者如果不按時(shí)進(jìn)行操作，就會(huì)對(duì)發(fā)包者和其他接包者造成損害。比如說(shuō)某接包者被算法1 選中卻遲遲沒(méi)有響應(yīng)或者拒絕任務(wù)，會(huì)導(dǎo)致發(fā)包者重新發(fā)布任務(wù)，而已加入委員會(huì)的其他接包者需要等待委員會(huì)組建成功之后才能開(kāi)展任務(wù)。此外，不按時(shí)提交結(jié)果數(shù)據(jù)也會(huì)損害眾包結(jié)果的可靠性。

2.3.3 信譽(yù)機(jī)制

為使眾包有序進(jìn)行，本文設(shè)計(jì)了接包者與發(fā)包者能夠交叉檢驗(yàn)對(duì)方行為狀況的機(jī)制。接包者在調(diào)用相關(guān)接口時(shí)，CSM 合約會(huì)自動(dòng)檢測(cè)接包者的狀態(tài)，并對(duì)違規(guī)者進(jìn)行相應(yīng)懲罰。同樣地，如果接包者發(fā)現(xiàn)發(fā)包者未進(jìn)行相關(guān)操作，可以調(diào)用CSM 中的相關(guān)接口對(duì)其處罰。表1列舉了接包者和發(fā)包者的違規(guī)行為。在本模型中，合約會(huì)根據(jù)惡意行為對(duì)他人的損害大小而扣除惡意方的信譽(yù)值和押金，并將扣除的押金補(bǔ)償給受損害方。發(fā)包者的聲譽(yù)降為0 時(shí)就不能再發(fā)布任務(wù)，接包者則會(huì)被算法1 拒絕。因此，這些惡意參與者將很快被系統(tǒng)封鎖。

表1 用戶(hù)惡意行為懲罰Table 1 User malicious behavior penalty

3 實(shí) 驗(yàn)

本文根據(jù)兩階段提交機(jī)制和支付功能，實(shí)現(xiàn)了一個(gè)基于Solidity 編程的智能合約的原型系統(tǒng)。

3.1 算法隨機(jī)性驗(yàn)證

算法1 的無(wú)偏性由運(yùn)行在區(qū)塊鏈上的兩階段提交機(jī)制保證。為驗(yàn)證算法的隨機(jī)性，本文設(shè)計(jì)了如下實(shí)驗(yàn)。該實(shí)驗(yàn)測(cè)試一個(gè)由10 名接包者參與的眾包任務(wù)，報(bào)名者有100 人（不包括發(fā)包者），即一個(gè)從100 個(gè)報(bào)名者中選取10 名接包者的實(shí)驗(yàn)。本文分別模擬了100 個(gè)報(bào)名者中包含1～5 名惡意者的情況，并對(duì)每種情況進(jìn)行10 組實(shí)驗(yàn)。每組實(shí)驗(yàn)結(jié)果記錄10 000 次隨機(jī)選取中惡意者被選中的次數(shù)，然后計(jì)算出惡意者入選比例。由于該項(xiàng)實(shí)驗(yàn)只是驗(yàn)證算法的隨機(jī)性，為提升模擬效率，本文使用Java 實(shí)現(xiàn)了同樣的選人算法邏輯，而并非在區(qū)塊鏈上人工操作。

本實(shí)驗(yàn)選取的候選者中包含至少一名惡意者，才能視為惡意者入選，如此便可以將該實(shí)驗(yàn)轉(zhuǎn)化為如下的概率論問(wèn)題：報(bào)名池中有100 人，其中包含n名惡意者，從中選取10 人求惡意者入選的概率。假設(shè)選中每一個(gè)報(bào)名者的概率是相等的，則惡意者入選概率Pn=1?其中表示10 個(gè)候選者都不是惡意者的概率。繪制理論值和實(shí)驗(yàn)結(jié)果如圖5所示，可以看出算法1 的結(jié)果已經(jīng)與理論值相當(dāng)接近，有效驗(yàn)證了算法的隨機(jī)性。

圖5 惡意者入選比例Figure 5 Proportion of malevolent persons selected

3.2 系統(tǒng)可行性驗(yàn)證

為了驗(yàn)證本方案的所有功能，本文將已實(shí)現(xiàn)的智能合約本地區(qū)塊鏈調(diào)試成功后部署在以太坊區(qū)塊鏈Rospten 的測(cè)試網(wǎng)絡(luò)上。這是一個(gè)供全球區(qū)塊鏈開(kāi)發(fā)者調(diào)試智能合約的網(wǎng)絡(luò)，其加密貨幣Ether 沒(méi)有真正的價(jià)值。本文創(chuàng)建了多個(gè)賬戶(hù)模擬發(fā)包者和接包者，并測(cè)試了所有可能的場(chǎng)景以開(kāi)發(fā)和驗(yàn)證不同接口的功能。由于兩階段提交機(jī)制和無(wú)偏隨機(jī)算法保證了系統(tǒng)的可靠性，因此本文主要分析一些從實(shí)驗(yàn)中得到的性能信息。性能是指接口的復(fù)雜性，它決定了用戶(hù)需要支付給以太坊礦工的交易費(fèi)用Gas。接口越復(fù)雜,礦工在執(zhí)行交易時(shí)消耗的算力越大，用戶(hù)支付的Gas 也就越多。無(wú)論是在主網(wǎng)還是在測(cè)試網(wǎng)，所消耗的Gas 幾乎是一樣的，于是本文記錄了實(shí)驗(yàn)過(guò)程中每個(gè)接口消耗的Gas。實(shí)驗(yàn)案例是一個(gè)由5 名接包者參與的50 幅圖像的標(biāo)注任務(wù)，每一名接包者標(biāo)注40 幅圖像。

本文測(cè)試了在眾包過(guò)程中每一種可能出現(xiàn)的情況，記錄了每個(gè)接口使用的Gas，并取10組測(cè)試的平均值如圖6和7 所示。UM 中的大部分接口是接包者和發(fā)包者都需要調(diào)用的，Gas消耗普遍較低；generateCS 只能由發(fā)包者調(diào)用，這是因?yàn)樵摻涌谛枰嗟拇鎯?chǔ)空間來(lái)生成和部署新的CS 合約，所以消耗的Gas 也最多。

圖6 UM 合約中各接口的平均Gas 量Figure 6 Average Gas volume per interface in UM contracts

在CS 合約中，有些接口只需發(fā)包者調(diào)用，而有些則需接包者單獨(dú)調(diào)用，在圖7中分別用豎線(xiàn)和斜線(xiàn)表示。在W的所有接口中，acceptCS 接口消耗的Gas 最多。因?yàn)楫?dāng)W接受任務(wù)時(shí)，TPS 需要為其初始化數(shù)據(jù)，這涉及到較多的存儲(chǔ)操作，而在以太坊上的存儲(chǔ)操作會(huì)消耗較多的Gas。在一般情況下，發(fā)包者調(diào)用的接口比W調(diào)用的接口耗費(fèi)更多的Gas，顯然符合模型設(shè)計(jì)和實(shí)際情況，這是因?yàn)樵诖蠖鄶?shù)情況下，發(fā)包者獲得的眾包數(shù)據(jù)會(huì)給它帶來(lái)更大的收益。與誠(chéng)實(shí)回答的回報(bào)相比，W消耗的Gas 是微不足道的，這足以說(shuō)服潛在用戶(hù)在系統(tǒng)中注冊(cè)并參與眾包。

圖7 CS 合約中各接口的平均Gas 量Figure 7 Average Gas volume per interface in CS contracts

4 相關(guān)眾包機(jī)制分析

現(xiàn)有的基于區(qū)塊鏈和智能合約的相關(guān)安全技術(shù)處于萌芽發(fā)展階段，尚未形成完整的應(yīng)用監(jiān)管體系，特別是在眾包場(chǎng)景中還沒(méi)有成熟的應(yīng)用。只有對(duì)于一些特定的場(chǎng)景或環(huán)節(jié)，比如眾包系統(tǒng)中的數(shù)據(jù)隱私、任務(wù)分配、工資支付等問(wèn)題，已有一些解決方案。

文獻(xiàn)[7-13]解決了集中式眾包系統(tǒng)中任務(wù)匹配的穩(wěn)定性和隱私性問(wèn)題；文獻(xiàn)[14-18]采用聲譽(yù)機(jī)制，解決了集中式系統(tǒng)中惡意參與者的問(wèn)題；文獻(xiàn)[19-20]將博弈論應(yīng)用于區(qū)塊鏈系統(tǒng)，建立了可信的分布式系統(tǒng)；文獻(xiàn)[21-26]也提出了一些去中心化眾包系統(tǒng)：以上系統(tǒng)的詳細(xì)比較如表2所示。經(jīng)綜合分析表明，這些系統(tǒng)并不是完全可信的，其原因在于：現(xiàn)有方法或是只注重于眾包任務(wù)建設(shè)，或是只注重于薪酬托管，或是只注重于數(shù)據(jù)管理，而這些都只是眾包活動(dòng)的一個(gè)環(huán)節(jié)而已。

表2 現(xiàn)有眾包平臺(tái)特點(diǎn)Table 2 Features of existing crowdsourcing platforms

5 結(jié) 語(yǔ)

本文針對(duì)眾包系統(tǒng)提出了一種基于承諾機(jī)制的兩階段提交機(jī)制，進(jìn)而設(shè)計(jì)了一種可以保證接包者獨(dú)立性的無(wú)偏隨機(jī)算法，最后通過(guò)智能合約在以太坊上實(shí)現(xiàn)了原型系統(tǒng)，并通過(guò)實(shí)驗(yàn)證明了所提出平臺(tái)的可行性。

對(duì)于未來(lái)的工作，我們有兩個(gè)主要目標(biāo)：完善系統(tǒng)和提高性能。一方面會(huì)擴(kuò)展更多的功能，讓系統(tǒng)適合更多的眾包場(chǎng)景；設(shè)計(jì)更人性化的界面，便于用戶(hù)操作。另一方面將進(jìn)一步優(yōu)化acceptCS 等接口的實(shí)現(xiàn)，減少Gas 消耗，降低用戶(hù)成本。一個(gè)可行的想法是引入能反映接包者專(zhuān)業(yè)技能的標(biāo)準(zhǔn)，并將其作為選擇算法和聲譽(yù)體系的參考。這個(gè)標(biāo)準(zhǔn)不僅可以豐富現(xiàn)有系統(tǒng)的功能，而且能讓接包者更容易利用自己的優(yōu)勢(shì)，讓發(fā)包者找到更專(zhuān)業(yè)的相關(guān)接包者，大大提高眾包的效率。