DVP專注于區(qū)塊鏈的什么問題

2008 年 11 月，“中本聰”發(fā)表論文《比特幣：一種點對點的電子現(xiàn)金系統(tǒng)》，提出了區(qū)塊鏈這種數(shù)據(jù)結構，區(qū)塊鏈技術和行業(yè)迎來了爆發(fā)式的增長和關注。

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

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

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

因此，區(qū)塊鏈安全變得尤為重要，與區(qū)塊鏈行業(yè)同步發(fā)展刻不容緩。

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

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

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

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

DVP 協(xié)議和公鏈

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

協(xié)議包含主要的懸賞支付系統(tǒng)：

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

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

1. 參與者

白帽子

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

廠商任務發(fā)布者

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

仲裁機構（治理結點）

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

普通節(jié)點

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

2. 區(qū)塊信息結構

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

3. 懸賞合約

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

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

4. 架構圖

普通節(jié)點：用于接受治理結點的廣播的區(qū)塊信息存儲記錄，保證整個網(wǎng)絡的數(shù)據(jù)去中心化。

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

DVP 去中心化平臺

DVP 公鏈發(fā)布后，搭建在線的漏洞信息展現(xiàn)平臺（區(qū)塊信息瀏覽器）

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

漏洞列表

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

提交漏洞

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

廠商發(fā)布懸賞合約

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

自定義活動

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

注冊廠商

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

注冊白帽子

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

登陸

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

廠商列表

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

廠商信息頁

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

排行榜

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

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

公共頁面

廠商發(fā)布懸賞合約顯示平臺的最新的動態(tài)，新聞。

獎勵計劃說明

說明漏洞的懸賞規(guī)則。

漏洞說明頁面

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

1. DVP 流程示例

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

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

（3）當廠商對漏洞產(chǎn)生任何疑問的時候，廠商可以將該漏洞事務重新寫入?yún)^(qū)塊發(fā)送給仲裁機構（治理結點），這時候由仲裁機構（治理結點）進行仲裁，然后進行漏洞判斷，仲裁結果以驗證者投票決定結果，超過 50%的票數(shù)將決定漏洞的裁定，然后將狀態(tài)廣播到網(wǎng)絡。

（4）漏洞被提交寫入?yún)^(qū)塊后，超過 24 小時未被處理，將自動進行消息推送給項目方提醒。

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

漏洞標題

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

基本信息

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

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

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

漏洞描述

漏洞簡述：包含漏洞概述

漏洞正文

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

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

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

修復建議

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

3. 漏洞信息

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

1. 廠商未確認

當漏洞報告被提交寫入?yún)^(qū)塊后，漏洞報告會自動加蓋時間戳，超過 24 小時未處理，將自動觸發(fā)聯(lián)系廠商動作。在沒被任何人確認的情況下將顯示“廠商未確認”。

2. 廠商確認完成

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

3. 爭議

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

4. 公開

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

4. 廠商審核漏洞

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

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

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

5. 業(yè)務獎勵

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

優(yōu)勢

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

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

1. 完全的隱私保護

白帽子不用體現(xiàn)真實身份

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

企業(yè)的漏洞只有自身能夠看到

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

2. 匿名設計，公平性

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

3. 去中心化的審查機制

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

來源： 區(qū)塊網(wǎng)