根據coinmarketcap統計，2019年6月，區塊鏈加密貨幣的市值就已經突破了2500億美元，2018年初更是一度突破8000億美元，已經在市場流通的加密貨貨幣高達2000多種，再考慮到未反映在其中的交易所、錢包、挖礦、媒體等相關產業，整個行業已初具規模，且仍有較大的成長速度和成長空間。

另一方面，區塊鏈行業仍處于初級發展階段，技術和理念的不成熟造成安全問題頻出，加之區塊鏈產品多具有金融屬性，鏈上資產在很多國家又不受法律保護的，且去中心化屬性導致資產難以控制和追索，使得區塊鏈項目成為黑客理想的攻擊目標。

據統計，區塊鏈相關的安全事件造成的損失一直處于上升的趨勢。 BCSEC的統計數據顯示，2018年區塊鏈重大安全事件數量達到創紀錄的139起，造成的經濟損失為 22.38億美元，歷史最高；2019年上半年重大安全事件已達68起，造成的經濟損失為6.84億美金；攻擊手段層出不窮，難以招架。

因此，區塊鏈安全變得尤為重要，與區塊鏈行業同步發展刻不容緩。

然而，與區塊鏈安全的嚴峻形勢相對應的，是區塊鏈安全公司和安全研究人員匱乏的現狀。在這種情況下，區塊鏈的發展是沒有保障的，尤其考慮到當前的區塊鏈企業多為初創企業、中小企業，資金實力有限，難以聘請到專業的安全研究人員對自己的區塊鏈產品進行持續的安全測試。

在這樣的條件下，安全眾測是理想的解決方案，可以更加靈活地對區塊鏈安全人員進行動態分配，更好地支撐區塊鏈的發展。區塊鏈企業可以對安全測試進行懸賞，激勵白帽子自發去尋找區塊鏈的潛在漏洞，依靠白帽子的力量發現安全問題并及時排除。然而，這一模式的問題在于：廠商和白帽子如何建立信任關系。

而信任問題，正可以通過區塊鏈技術來彌補。通過區塊鏈技術搭建可信任的漏洞平臺，再反過來為區塊鏈安全提供保障，彼此相輔相成，可以真正做到區塊鏈與區塊鏈安全同步發展。

基于這樣的理念，為了更好的保護區塊鏈生態安全，BCSEC 和 PeckShield 共同發起建立了 DVP——Decentralized Vulnerability Platform，去中心化漏洞懸賞平臺。

DVP 協議和公鏈

DVP 協議通過創建可伸縮低成本的系統，來解決區塊鏈項目的安全問題。隨著時間的推移，我們希望每一個區塊鏈項目都能使用 DVP 協議來執行安全審計，因為在區塊鏈項目中安全是最基本的要求。

協議包含主要的懸賞支付系統：

一個自動的賞金支付系統，用于獎勵查找漏洞的人工參與者，建立白帽子與項目方的一個自動懸賞支付系統。

DVP 協議依賴于參與者們的分布式網絡，來減輕壞角色的作用，提供所需的算力，還有提供治理。每一個參與者都使用 DVP 協議積分來支付、接收，或者提高驗證服務。

1. 參與者

白帽子

通過發現漏洞獲得積分作為賞金，通過平臺查看懸賞任務，發現漏洞后通過平臺，或者客戶端將報告用廠商的公鑰進行內容加密提交。

廠商任務發布者

廠商生成后需要等待治理結點仲裁機構進行廠商身份確認，完成后將由任務發起方，發布任務，填入懸賞標準，以及測試范圍信息，并且存入，將生成私鑰，公鑰信息，公鑰用于提交者加密提交漏洞信息，私鑰用于查看安全測試報告內容，對于未注冊的廠商漏洞將自動發送到治理結點仲裁結構查閱。

仲裁機構（治理結點）

運行 DVP 驗證節進行仲裁判定，并且用于所有區塊的記賬寫入數據操作，然后進行廣播，最終并獲得積分激勵，該節點需要是具備安全驗證能力的節點（可以為個人，團隊，組織，或者公司）最終會在漏洞的提交者與項目廠商之間產生爭議的時候，由治理結點進行投票裁定結果 。

普通節點

任何一個客戶端都是一個普通節點，普通節點作為 DVP 的分布式數據存儲，但沒有寫入權限，最終區塊內容由仲裁機構治理結點維護寫入。

2. 區塊信息結構

寫入操作最終由治理結點進行寫入記賬操作，內容只能新增，不能刪除修改。整個信息結構將由仲裁機構維護（治理結點）

3. 懸賞合約

生成 DVP 的廠商賬號，在項目設置中填寫測試目標和漏洞獎金等信息，提交后等待治理結點審核廠商身份，完成廠商賬號押金充值，即可開始公開懸賞項目。

懸賞合約將通過在線的 B/S 客戶端，或者 C/S 客戶端，移動端等進行任務發布，內容對每個等級的漏洞懸賞定義，例如：高危 1000$， 中危 500$，低危 200$；項目審計的資產范圍，可以是錢包、公鏈項目，或者某個系統等；漏洞定義將對每個等級的情況進行說明；

4. 架構圖

普通節點：用于接受治理結點的廣播的區塊信息存儲記錄，保證整個網絡的數據去中心化。

治理結點：用于廣播記賬計算全網的交易，懸賞，合約等信息記錄，將由擁有一定安全能力的安全廠商運營

DVP 去中心化平臺

DVP 公鏈發布后，搭建在線的漏洞信息展現平臺（區塊信息瀏覽器）

在線展現平臺主要用于提交漏洞，廠商注冊生成，白帽子注冊生成，包含廠商列表，廠商信息頁，排行榜頁面，公告頁面，獎勵計劃說明頁面，漏洞說明頁面，但是整個平臺的數據是去中心化的，只是一個在線的客戶端 DVP 瀏覽器，用于展現區塊中的數據。同時形成一個安全生態社區，聚集更多的白帽子與項目方的入駐。

漏洞列表

顯示漏洞的列表，其中包含，漏洞標題，漏洞提交公鑰地址，漏洞對應的廠商，漏洞獎金，漏洞發布時間。

提交漏洞

白帽子提交漏洞的入口，白帽子需要提交漏洞標題，影響廠商，官方網站，類型，危害，自評分，自評等級，簡介，詳情，驗證代碼（PoC），修復建議。

廠商發布懸賞合約

廠商填入安全審計的資產范圍，懸賞標準后，直接將押金存入合約，懸賞合約將通過治理結點進行廣播寫入全網區塊。

自定義活動

廠商項目方可以自定義時間段，節假日發起特定時間段的懸賞活動，除了正規的懸賞合約信息外指定合約有效期。

注冊廠商

填入廠商聯系郵箱，廠商官方主頁，介紹信息，然后轉入相應的押金，注冊完成后會自動生成相關私鑰，公鑰，作為廠商后續登入的唯一憑證。公鑰也是錢包地址

注冊白帽子

填入個人介紹，昵稱，注冊完成后 生成相關私鑰，公鑰。作為廠商后續登入的唯一憑證。公鑰也是錢包地址

登陸

通過私鑰即可登入自己的個人頁面。

廠商列表

廠商列表部分則主要顯示廠商的名字，廠商的網站地址，廠商注冊時間。

廠商信息頁

除顯示廠商信息外，還顯示廠商介紹，廠商發放獎金情況，廠商個人信息管理，以及廠商對應的漏洞提交情況。

排行榜

排行榜分為白帽子積分排行榜，廠商獎金方法排名。白帽子排行榜根據白帽子提交漏洞所得積分進行排名，排名為季度排名，展現當季度的所有漏洞信息合集。

每個季度在 DVP 協議中將自動按照排名選擇 top10 的白帽子進行積分獎勵，以保證整個社區的活躍度積極性。

公共頁面

廠商發布懸賞合約顯示平臺的最新的動態，新聞。

獎勵計劃說明

說明漏洞的懸賞規則。

漏洞說明頁面

漏洞對應的危害等級，積分，獎金計算規則說明。

1. DVP 流程示例

（1）任何一家區塊鏈廠商將可以通過我們的官方平臺（在線的客戶端）提交發布懸賞標準，測試范圍（可以是合約，也可以是任何公鏈項目等），提交后存入相應倍數的積分到獎金池，完成操作后將自動為該懸賞事務生成公鑰（加密漏洞內容），私鑰（廠商查看安全報告內容）

（2）漏洞提交者同時也可以通過我們的官方平臺（在線客戶端）實時查看目前在區塊里發布寫入的懸賞事務，選擇自己要參與的，當發現漏洞后可以通過該廠商公布的公鑰進行加密漏洞內容，然后發送，廠商則可以在區塊獲取跟自己有關的漏洞信息，然后進行解密查看，當對漏洞進行確認后，事務會自動對該漏洞的提交者進行發布的標準獎勵（根據漏洞的高中低等級確認）。

（3）當廠商對漏洞產生任何疑問的時候，廠商可以將該漏洞事務重新寫入區塊發送給仲裁機構（治理結點），這時候由仲裁機構（治理結點）進行仲裁，然后進行漏洞判斷，仲裁結果以驗證者投票決定結果，超過 50%的票數將決定漏洞的裁定，然后將狀態廣播到網絡。

（4）漏洞被提交寫入區塊后，超過 24 小時未被處理，將自動進行消息推送給項目方提醒。

2. 提交的漏洞報告要求：

漏洞標題

標題描述：標題可基本概括漏洞情況，描述語言缺乏規范性。如“一處注入漏洞”“另外一處注入”“網站某處存在越權”

基本信息

漏洞類型：填寫信息準確無誤

漏洞等級：填寫信息準確無誤

廠商信息：填寫信息準確無誤，

漏洞描述

漏洞簡述：包含漏洞概述

漏洞正文

漏洞復現過程：復現過程基本完整，個別地方描述不清或缺少數據，對漏洞評估、復現有一定影響

分步驟圖文描述：關鍵測試步驟完整，但復現步驟缺失，對漏洞復現有一定影響。如直接粘貼出漏洞利用請求包，但缺乏測試步驟如何獲取此請求包，需要二次溝通方才可復現

漏洞危害證明：漏洞危害證明基本完整

修復建議

漏洞修復建議：修復建議基本無誤，但過于簡單，無實際參考意義。如“控制權限”，“過濾參數”，“校驗身份”

3. 漏洞信息

漏洞報告整個信息體由公鑰進行加密，只有廠商可以使用私鑰進行解密

1. 廠商未確認

當漏洞報告被提交寫入區塊后，漏洞報告會自動加蓋時間戳，超過 24 小時未處理，將自動觸發聯系廠商動作。在沒被任何人確認的情況下將顯示“廠商未確認”。

2. 廠商確認完成

廠商可以查看自己懸賞合約的相關漏洞信息，通過私鑰能解密得到報告內容詳情，然后進行判斷，當無誤時，懸賞動作將自動打入該漏洞提交者的地址。

3. 爭議

爭議是指目前提交的漏洞信息，廠商不予認同，存在疑問，這時候需要廠商發送解密過后的漏洞細節報告給仲裁節點，進行投票仲裁，最終結果以投票數》50%的結論進行裁定。

4. 公開

在廠商主導確認下可以發布漏洞公開內容，進行披露漏洞細節，這些內容將被寫入到區塊中，供大家查看。

4. 廠商審核漏洞

廠商發布懸賞合約后，能通過客戶端+私鑰登入 DVP 主網，查看提交的漏洞細節，當漏洞被確認后，將自動完成轉賬懸賞操作，當出現異議時：

漏洞重復：按照提交時間以提交時間最早的為準，后面提交的廠商有權拒絕，發起仲裁。

漏洞無效：廠商認為該漏洞無效，無法復現，或者無危害，這時候廠商將細節解密重新加密發送給仲裁節點進行投票仲裁。根據仲裁結果，如果確定有效自動轉入提交者的錢包地址，非有效漏洞，將直接廣播全網告知該漏洞無效。

5. 業務獎勵

DVP 平臺將對每筆業務收取一定比例的礦工費（初始參數設置為 10%），形成獎勵池，用于獎勵回饋對 DVP 社區生態貢獻價值的廠商和白帽子（初始參數比例 3：7）。廠商和白帽子所貢獻的價值將按照一套規則透明的排名算法計算，算法細則請關注官方網站的披露。

優勢

漏洞懸賞源起于美國，前有 Facebook，Google，微軟；后有 HackerOne，BugCrowd 等商業公司，通過白帽社區幫助企業發現安全漏洞。國內 3BAT 等一線互聯網廠商均有 SRC（安全應急響應中心）進行漏洞懸賞計劃，他們通過這種方式使外部漏洞數量直線下降至可控范圍內，為自己長線的安全體系建設贏得時間和方向指引。

但是目前市面上還沒有一個去中心化的漏洞懸賞平臺。所有的懸賞任務，都是通過中心化的平臺，或者郵件等方式溝通，低效且耗時，限制了懸賞活動的使用范圍，并且它要求企業雇用專門的人員審核所有的懸賞任務，而提交者又不愿意過多的暴露自己的身份，以及聯系方式等個人隱私。而現有平臺都沒有解決這些問題， 市面上現有的 Bug Crowd 和 Hackerone 等其他網站，側重于傳統的網絡安全問題，且沒有提供去中心化的審查機制，而 DVP 的核心價值點就在于，隱私保護，以及匿名的設計，以及去中心化的審查機制來保障漏洞的保密性，公平性。

1. 完全的隱私保護

白帽子不用體現真實身份

目前其他的懸賞平臺都需要提交者提供私人信息，包括領取獎勵的信息，提交漏洞的安全人員多數不愿意透露自己的個人信息，很多白帽子因為不愿意跟廠商溝通，以及留下個人信息等原因放棄提交漏洞，而 DVP 的匿名性等特點能有效的保護白帽子個人隱私，所以能更好的吸引更多的白帽子參與。

企業的漏洞只有自身能夠看到

提交漏洞只與廠商進行結果確認，保證漏洞的保密性，當出現爭議時候，由過個治理結點投票決定保證公正性，目前現有的漏洞平臺都是基于中心化的平臺，所以平臺方是能查看到所有項目方的漏洞信息，而廠商項目方并不想把這些信息給平臺方查看，歷史上就有因為中心平臺方的問題導致漏洞細節被暴露，最終導致漏洞細節被二次利用，使廠商遭受損失，而目前 DVP 的對稱加密方案結合公鏈的方式讓漏洞細節只有廠商能查看，且最終的公開與否的權利都在廠商手上，有效的保證了漏洞細節的保密性。

2. 匿名設計，公平性

懸賞獎勵交易匿名記賬，對于獎勵無需任何個人信息，且任何的獎勵懸賞記錄都能公開透明，保證公平公正性。每筆懸賞都有歷史的記錄，能完整的溯源獎勵記錄。

3. 去中心化的審查機制

所有的審核標準都由廠商來確認，傳統的漏洞平臺，通常都由中心平臺來進行審核驗證漏洞，中心平臺擁有絕對的控制權，對于漏洞有疑問的地方，白帽子或者廠商是沒有話語權的，而 DVP 以去中心化的機制進行審核，廠商在出現異議的時候，由仲裁方（治理結點）進行仲裁投票方式審核該漏洞保證絕對的公平性。
來源；區塊網