概要
2008 年 11 月，“中本聪”发表论文《比特币：一种点对点的电子现金系统》，提出了区块链这种数据结构，区块链技术和行业迎来了爆发式的增长和关注。
根据 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 以去中心化的机制进行审核，厂商在出现异议的时候，由仲裁方（治理结点）进行仲裁投票方式审核该漏洞保证绝对的公平性。