Audit+ Blue Paper (Chinese)

EOS Audit+
Blue Paper
提升EOSIO区块链的安全性
PartI
2022

致谢
EOS 网络基金会 (ENF) 谨向 Audit+ 蓝皮书的主要作者表示诚挚的感谢。
Sentnl — 区块链审计公司，
专门从事EOSIO区块链的渗透测试、
钱包安全审计和智能合约审计。
Slowmist — 区块链安全公司，
提供的解决方案包括安全审计、
威胁情报
（BTI）
、
漏洞赏金、
防御部
署、
安全咨询以及其他针对EOSIO项目的服务

目录
目录��1
摘要��3
一. 社区现有方案��5
1) Klevoya Inspect ��5
A) 简介��5
B) 特性��5
C) 对EOSIO的益处
��5
D) 参考材料 ��6
2) 软件开发库 ��6
A) 简介��6
B) 特性��6
��7
D) 参考文档��7
二. 社区提议的解决方案��8
1) 智能合约安全开发库 ��8
A) 简介��8
B) 提议依据��8
C) 方案提议者��8
2) 漏洞赏金计划 ��9
A) 简介��9
3) 合约升级授权DAO ��9
A) 简介��9
C) 方案提议者��10
三. 其他区块链生态中存在的相似举措
��11
1) dApps 安全注册机制 ��11
A) 简介 ��11
B) 特性��12
C) 重点规避
��12
2) 开源安全工具
��12
A) 简介��12
B) 特性�� 13
C) 重点规避
�� 13
D) 参考材料 �� 13
3) 智能合约安全开发库 ��14
A) 简介��14
B) 特性��14
C) 重点规避
��14
4) 编写智能合约时常见的安全缺陷 �� 15
A) 简介�� 15
B) 特性�� 15
C) 重点规避
�� 15
D) 参考材料 �� 15
5) 漏洞赏金计划 ��16
A) 简介��16
B) 特性��16
C) 重点避免
��16
6) 反洗钱平台 ��17
A) 简介��17
B) 特性��17
C) 重点避免
��17
D) 潜在商机
��17
E) 参考材料��17
四. 改善 EOS 生态系统的举措清单 ��18
1. 开源的安全审计API和平台 ��18
A) 痛点��18
B) 目标��18
��19
D) 交付成果��19
E) 投入水平��21
F) 最小化可行产品��21
G) 最小化可行产品的进阶 �� 22
H) 未来目标 �� 23
I) 参考材料 �� 23
2. 智能合约升级DAO �� 23
A) 痛点 �� 23
B) 目标 ��24

C) 对EOSIO的益处 �� 25
D) 产出成果 �� 25
E) 投入水平 �� 25
F) 商业机会 ��26
G) 最小可行产品 ��26
H) 参考材料 ��26
3. 创建反洗钱平台 ��26
A)痛点 ��26
B) 目标 ��27
��27
D) 产出成果��27
F) 最小化可行产品 ��28
G) 未来目标 ��29
4. 智能合约安全开发库
��29
A) 痛点��29
B) 目标 ��29
��30
D) 产出结果��30
F) 最小可行产品��30
G) 未来目标��31
5. 漏洞赏金计划
��31
A) 痛点��31
B) 目标��31
��31
F) 最小可行产品 ��33
G) 未来目标�� 34
H) 参考材料 �� 34
6. 开发自动化的安全审计工具 �� 34
A) 困境�� 34
B) 目标�� 34
��35
E) 付出水平��35
F) 最小可行产品��36
G) 参考材料 ��36
7. 建立编写EOSIO智能合约时易犯安全缺陷列表 ��36
A) 痛点��36
B) 目标��37
��37
D) 产出物��37
F) 最小化可行产品��38
G) 参考材料 ��38
五. 致基金会的最佳行动方案提议清单
��39
1. 编写 EOSIO 智能合约时常见的安全缺陷列表 ��39
2. 智能合约安全开发库 �� 40
�� 40
4. 开源的安全审计 API 和平台 ��41
六. 附录 ��42

摘要
本报告旨在介绍如何提高EOSIO区块链整体安全性的研究和举措。
我们的研究表明，
当前市场上鲜少有针对如何提高EOSIO安全性的专项解决方案。
EOSIO核
心系统设计极其精妙，
其允许采用面向安全的方法，
但需要做大量工作以使得EOSIO达到与
其他区块链相同级别的安全标准。
本文的一个重点领域是知识：
这个知识可以是开发者社区中可自我延续的知识，
其必要实现途径是向开发者社区提供正确
的工具和文档;
这个知识可以是用户群体对EOSIO安全性的共识，
基于EOSIO独特的设计结构，
只需提供底
层性的基础服务和API，
完全可以实现他们与EOSIO dApps之间安全可靠的交互。
如前所述，
EOSIO整体核心设计允许采用面向安全的方法，
我们只需专注于基础设施，
并在此
之上利用一些EOIO的关键元素，
助推EOSIO在与其他区块链的竞争中脱颖而出。

阅读须知
本报告提供的指导建议如下所示：
1. 当前的解决方案：
本文第一部分介绍了当前EOSIO社区现有的可用解决方案。
.
2. 社区呼吁的解决方案：
本文第二部分介绍了社区中呼声最高的解决方案。
3. 当前非EOSIO社区中的解决方案：
本文第三部分介绍了其他区块链社区中现存的，
可被运用到
EOSIO中的解决方案。
4. 我们的提议举措：
本文的倒数第二部分
（即第四部分）
重点介绍了我们认为如何提高 EOSIO整体
安全性的全部举措。
5. 在本文的最后部分
（即第五部分）
，
列举了我们认为最适合启用的4项基础性举措，
这些措施将构
建EOSIO的安全基础。
6. 附录部分则提供了一些读者可能不熟悉的术语名称解释。

一. 社区现有方案
尽管EOSIO社区中已存在若干解决方案，
但整体而言，
我们认为普遍缺乏面向基础安全的解决方案。
下文中我们将介绍一些常被提及且正在使用的解决方案。
1) Klevoya Inspect
A) 简介
Klevoya inspect是一个允许开发人员上传编译后的WASM代码，
并根据Klevoya团队创建的独特模
式去检查代码是否存在漏洞的软件。
Klevoya inspect采用的是静态分析安全检测技术。
静态分析是在不真正执行代码的情况下，
对计算
机程序的源代码或IR
（译者：
Intermediate Representation, 可译作中间表示。
IR是程序编译过程
中，
源代码与目标代码之间翻译的中介）
进行分析。
在后台，
上传的 WASM 代码和 ABI 先被上传成专门的IR
（中间表示）
并加载至Klevoya inspect数据
库，
随后系统的模式匹配机将遍历数据库中的所有实体
（译者：
实体在这里指Klevoya inspect数据库
中已建立的已知漏洞集合）
，
去寻找上传的代码是否存在上述这些已知漏洞。
该产品不是开源的，
且是付费服务。
B) 特性
1. 自动对上传的编译好的WASM代码进行扫描分析。
2. 扫描引擎基于系统内部设计好的模式进行漏洞检测。
尽管此功能是付费服务，
且不能保证达到与人工执行的安全审计相同的漏洞覆盖深度，
但静态分析

模糊测试是一个非常强大的工具，
它可以为开发人员一个独特的机会，
即可以自我诊断和解决安全问
题，
日积月累之下，
开发人员将逐渐精通并编写更具安全性的智能合约。
D) 参考材料
• https://klevoya.com/inspect/index.html
• https://klevoya.medium.com/?p=242400e10cdc
• https://www.fuzzingbook.org/html/ConcolicFuzzer.html#SMT-Solvers
2) 软件开发库
A) 简介
EOSIO提供了一个eosio.contracts合约库，
包含bios、
system、
msig、
wrap和token合约。
由于这些
代码采用MIT许可协议
（译者：
MTI许可协议是当前国际上五种常见的开源协议之一）
，
开发者使用这
些代码几乎不受任何限制，
他们甚至可以通过学习这些合约
（包括治理参数和经济模型）
管理EOS主
网。
除eosio.contracts合约仓库以外，
社区中还有一些通用的 SDK：
• SX 组织在 Github 上开源了 9 个 DeFi 类型的智能合约
（内含良好的编码标准）
，
且有一些合约已
通过安全审计，
但应该注意的是，
这些库并没有指明要遵守的版权协议。
• Blockmatic收集了 112 个社区开源的 EOS 智能合约源代码并公之于众。包含游戏、
DeFi、
支
付、
DAO、
稳定币、
NFT、
1CO等各类合约示例，
甚至还有使用Rust作为开发语言的项目，
让我们
看到了开发者对EOS合约开发的热情。
B) 特性
目前，
社区有不少的开源代码示例，
但经过安全审计的代码相对较少，
且这个数量比以太坊少了几个
数量级。
需要注意的是，
大多数的代码库都已经暂停维护了。

开发人员是区块链发展的关键角色之一。
如何吸引更多的开发者进入EOSIO生态系统是EOS社区需要
思考的重要问题。
通过开发和共享高质量的开源代码库，
可以降低开发难度，
即使是经验不足的开发
人员也可以快速开发安全的智能合约，
从而促进EOS被广泛应用。
D) 参考文档
• https://github.com/EOSIO/eosio.contracts
• https://github.com/stableex
• https://github.com/blockmatic/eosio-contracts-list

二. 社区提议的解决方案
基于我们的研究以及与EOSIO社区利益相关者的交谈，
在此列出了一些我们认为社区提议的关键性
解决方案，
这些方案将有助于提高EOSIO生态系统的整体安全性。
1) 智能合约安全开发库
A) 简介
智能合约安全开发库
（SDK）
允许软件开发人员利用久经实践考验的合约模板和库来开发智能合约，
从而使安全风险最小化。
智能合约安全开发库就像标准的SDK一样，
但与SDK相比，
其内部还预构建了若干执行某些操作的实
例，
由于这些实例是基于最佳安全实践的，
所以你可以直接选用这些已通过安全审查的代码来执行特
定操作，
而不需要自己从零编写。
B) 提议依据
使用此类软件库不仅有助于在创建智能合约时将风险降至最低，
因为它们可以帮助开发人员使用已
经通过安全审查的已知方法，
而且还允许开发人员在单元测试中包含安全测试。
如果 EOSIO 社区的所有开发人员都开始使用相同的 SDK 列表，
为了解决 EOSIO 上的最新安全问题，
这些 SDK 会由开发者社区自发更新。
对于容易避免的错误，
开发人员完全可以避免，
这将有利于提高
智能合约的整体安全性。
C) 方案提议者
那些希望开发更具安全性的智能合约的EOSIO 软件开发人员，
但现实是我们缺乏此类整体工具。

2) 漏洞赏金计划
A) 简介
漏洞赏金计划是对成功发现应用程序或软件漏洞的白帽黑客予以金钱奖励。
该机制适用于所有区块链，
尤其是如果您的代码库不断变化或具有多种风格，
因为其可确保您的代码
源源不断地获得来自各类白帽黑客的安全审查。
B) 提议依据
拥有一个运行良好的漏洞赏金计划将吸引最优秀的黑客社区来提高 EOSIO 的整体安全性。
但缺乏此
类赏金计划的现状正在阻碍黑客社区投入时间和精力来研究 EOSIO 代码库。
C) 方案提议者
希望参与 EOSIO 的白帽黑客，
但只有在我们定义并启动运行良好的漏洞赏金计划后，
此类群体才会
投入时间和精力参与进来。
3) 合约升级授权DAO
A) 简介
在 EOSIO 中，
智能合约被部署在一个active 账户上，
通常该智能合约的开发人员拥有在未来升级该
智能合约的完整权限。
这就不可避免地导致了信任问题，
因为暂且不论这个智能合约的安全审计状态
如何，
本质上需要该智能合约的用户群信任active 账户所有者不会作恶
（恣意修改合约）
。
当然，
您完全可以移除任何人对智能合约的更新能力，
这当然可以在用户和智能合约所有者之间建立
信任，
但与之相伴的是该举措将剥夺对智能合约的任何更新可能性，
因为未来一旦发现需要补救的
bug或安全漏洞需要更新时，
也无能为力。
综上所述，
更合适的解决措施是构建特定类型的多重签名场景，
该场景不仅可以构建用户与智能合约
所有者之间的信任桥梁，
还允许智能合约所有者在必要时及时进行更新。

B) 提议依据
如前所述，
我们需要管理智能合约管理权限的更优解，
该方式不仅可以促进用户和智能合约所有者之
间形成更多信任，
还允许智能合约所有者保留对应用软件的更新能力。
C) 方案提议者
社区和智能合约所有者均需要此类功能。 dApp所有者希望其用户群能信任他们，
但也可在必
要时灵活地更新 dApp。尽管我们不可能保证社区正在使用的 dApp 永远不会面临被黑客攻
击的风险，
也不能确认dApp 所有者意图的好坏，
但提供这种额外的信任层将有助于在社区和
dApp 所有者之间建立更多的信任。

三. 其他区块链生态中存在的相似举措
通过研究其他区块链的产品，
我们在本章列举了在其他Top区块链协议中常见且行之有效的安全方面
的内容和产品。
通常，
在如何实现系统安全的总基调方面，
这些区块链项目往往方向高度一致。
此外，
我们还将介绍一个颇具新颖性的创意，
该创意已在以太坊上取得成效，
在本文的后面章节中该
创意将作为我们提议的核心举措之一着重介绍。
1) dApps 安全注册机制
A) 简介
我们发现在以太坊中存在一个GitHub代码存储库，
它试图列出当前所有的智能合约信息，
包括该合
约其所部署的链、
账户地址和所属的相关项目。
从该代码存储库的历史记录来看，
该项目始于 2021
年 9 月，
这似乎是 ETH 链上颇具新颖性的尝试。
“目标是能够在用户与某一区块链地址发生交互时，
为用户提供该地址的相关信息，
一旦给定的合约
地址被发现存有漏洞时，
可以快速跟踪获取到已知项目的可靠联系信息。
”
目前支持的 ETH EVM 链列表如下：
1. Etherum Mainnet
2. Optimistic Ethereum
3. Binance Smart Chain
4. xDAI
5. Fuse
6. Polygon
7. Fantom Opera
8. Arbitrum

B) 特性
1. 列出您的项目：
为了列出您的项目，
您需要填写一份表格以列出您的项目详细信息，
包括项目名
称、
Github 地址、
联系电子邮件
（如有安全问题）
、
部署的链和智能合约地址。
2. 紧急联系人：
在列出您的项目时需要提供一个紧急安全联系邮件，
一旦发现您的合约存在严重的
安全缺陷时，
社区有办法通知您。
3. 自动安全联系人跟踪：
采用一种特定格式，
该格式允许开发人员通过代码注释的形式提供安全联
系人详细信息，
如此一来开发者可在智能合约创建时自动注册相关信息。
C) 重点规避
当前的解决方案似乎是一个非常手动的过程，
徒增了许多非必要的步骤，
在EOSIO中运用时应该更自
动化。
D) 参考材料
• https://github.com/ethereum-lists/contracts
2) 开源安全工具
A) 简介
开源安全工具是一种开发人员自我评估其智能合约整体安全性的便捷方法。尽管这些工具确实并不
多见，
往往只有几个Top区块链协议中存在此类工具，
但我们正在积极尝试改变这一现状。
这些工具
可促进开发者对智能合约代码安全的自我诊断，
且在开发者社区中逐渐培养其积累如何规避常见安
全缺陷的相关经验与知识。

B) 特性
此类工具中常见的、
友好的功能如下：
• 识别错误、
错误类型、
错误严重性以及显示该错误在源代码中的位置。
• 易集成至持续集成
（CI）
环境和 SDK 中。
• 提供允许开发人员编写自定义分析的API。
• 执行速度非常快。
• 代码大多是开源的，
可由开发者和安全社区共同维护
C) 重点规避
避免使用晦涩的语言开发此类工具，
避免一直封闭不开源相关源代码。
目前这类工具往往都是开源
的，
且选用一种非常适合此类分析的可编程语言如
（Python）
开发。
但是也有一些像 Solana 这样的
例子，
其唯一可用的工具是闭源代码，
大大限制了社区参与该工具并扼杀了它的发展。
D) 参考材料
• https://github.com/crytic/slither
• https://github.com/ConsenSys/mythril
• Soteria (Solana) -
https://medium.com/coinmonks/soteria-a-vulnerability-scanner-for-solana-smart-
contracts-cc202cf17c99

3) 智能合约安全开发库
A) 简介
这些专注于安全性的软件开发库用于指导智能合约的开发，
降低开发难度，
并提高代码质量和安全
性。
此类软件开发库就像您的标准 SDK 一样，
但与SDK相比还提供附加功能，
可帮助指导开发人员编写
更安全的代码。
通常由官方研发部门牵头，
或由知名项目方开发。软件库通常提供诸如token、
NFT、
借贷、
swap、
治理等应用的示例。
有些提供了合约开发中常用的功能，
比如safemath库，
它提供了防止算计运算溢
出。
B) 特性
这些软件开发库具有极佳的代码质量，
具体表现在：
• 每一类应用都有完整的功能实现；
• 简单和模块化的代码；
• 含义明确、
风格一致的函数和变量命名方式；
• 变量和函数功能注释说明；
• 全面的单元测试；
• 支持通用包管理工具，
如npm、
cargo；
• 经过更全面的安全审计。
C) 重点规避
应避免一次性外包开发，
安全开发库应持续不断更新，
并且开发者应尽可能为社区提供相关的技术支
持。
D) 参考材料

• https://github.com/OpenZeppelin/openzeppelin-contracts
• https://github.com/open-web3-stack/open-runtime-module-library
• https://github.com/solana-labs/solana-program-library
4) 编写智能合约时常见的安全缺陷
A) 简介
列明开发人员在某一区块链开发时曾犯的安全缺陷的文档，
且确保对此类缺陷的介绍是全面深入、
持
续更新的，
创建此类文档的目的在于帮助未来的开发人员避免重复犯相同错误。
将避免这些常见的安全缺陷视为要遵循的规则，
如此一来您的智能合约可最大化规避黑客攻击风
险。
B) 特性
常见安全缺陷列表往往会包含攻击类型描述、
若干个显示错误发生位置的源代码实例、
这些错误可
能导致的漏洞以及帮助开发人员在自己的代码中不重复犯相同错误的预防手段。
有时，
还会提供现实生活中已发生的黑客如何利用特定代码段的错误进行攻击的示例，
以帮助开发人
员深刻理解此类安全缺陷可能导致的潜在风险。
C) 重点规避
在我们的研究中，
我们注意部分安全缺陷文档存在
（译者: 如内容、
分类、
位置等）
分散且没有妥善的
更新维护。
我们应该避免将这些信息分散在太多地方，
理想情况下此类信息应该保留在Git的一个专
门类库中，
且所有参考材料均应该指向相同定位。
D) 参考材料
• https://medium.com/coinmonks/soteria-a-vulnerability-scanner-for-solana-smart-
contracts-cc202cf17c99

• https://blog.neodyme.io/posts/solana_common_pitfalls
• https://consensys.github.io/smart-contract-best-practices/known_attacks/
• https://github.com/sigp/solidity-security-blog
5) 漏洞赏金计划
A) 简介
大多数Top区块链项目要么运行自己的漏洞赏金计划，
要么借助于诸如hackerone、
bugcrowd和
Immunefi等可推进漏洞赏金计划的外部平台。
漏洞赏金计划是由不同网站、
组织和软件开发人员提供的交易。
在交易中，
上报者通过提供相关网
站、
软件等存在的缺陷，
尤其是与安全漏洞及漏洞有关的错误，
获得相应的认可和报酬。
B) 特性
• 对漏洞的明确分类定义、
严重性范围及对应的赏金。
• 关于构成一个bug的明确规则定义。
• 提交bug的明确程序定义。
• 每个特定漏洞赏金中顶级黑客排行榜。
• 良好的沟通和奖励支付机制。
• 与其他所有 EOSIO 链沟通与共享漏洞库以及对漏洞的公开公告。
C) 重点避免
与 ETH 一样，
EOSIO 已经成为多链，
因此在出现漏洞时，
需要采用标准化的方式与所有其他链进行
通信。
如此一来，
即便之后漏洞被公开，
黑客也无法利用它来攻击任何其他的 EOSIO 链。
应预留时间让所有链都有机会评估新分发的安全补丁并完成升级，
在此之前应该避免公开该漏洞。
因
此需要深思熟虑，
构建一种将 EOSIO 安全问题有效传递给关键人员的合适方法。
D) 参考材料

• https://ethereum.org/en/eth2/get-involved/bug-bounty/
• https://hackerone.com/cardano-foundation?type=team
• https://bugcrowd.com/vulnerability-rating-taxonomy
• https://immunefi.com
6) 反洗钱平台
A) 简介
EOS 是一个 DAO 系统，
很多决策都依赖于对链上信息的分析，
比如是否冻结一个涉嫌攻击智能合约
的黑客账户，
此时就需要一个分析此类行为的数据分析平台。建立反洗钱(AML)平台可以确保我们有
足够的手段来追踪黑客事件后的资金流向。
著名的以太坊区块浏览器 Etherscan 就建立了此类AML
平台，当黑客事件被披露时，
平台会帮助识别攻击者账户并标记为剥削者，
交易所等相关方通过查询
该平台的相关信息，
可确保与该账户有关发送和接收行为被阻断。
B) 特性
标记平台应该有足够的数据来保证账号标记行为的准确性，
并且在该区块链生态中有足够的参与度，
确保平台能够及时处理新的事件。
C) 重点避免
帐号标记少，
标记不准确，
对社区事件反应迟缓。
D) 潜在商机
或许可以提供一些付费的区块链分析服务。
E) 参考材料
• Etherscan Label Word Cloud: https://etherscan.io/labelcloud
• https://eosdetective.io/network

四. 改善 EOS 生态系统的举措清单
基于当前社区中已存在、
社区提议以及我们在其他区块链协议中看到的解决方案等样例，
我们提出了
帮助 EOSIO 在安全性方面占领先机的举措清单。
尽管要使我们达到与其他区块链相同的水平仍需做出一些努力，
但是一旦我们的基础设施建立起
来，
EOSIO 的独特设计将使我们能够超越其他区块链。
1. 开源的安全审计API和平台
A) 痛点
目前没有可供社区验证与其进行交互的智能合约代码是否经过审计并认定为安全的服务，
也没有供
安全审计员发布审计结果及关联信息的统一平台。
B) 目标
建立1个智能合约源代码验证平台和1个审计信息披露平台，
方便社区验证与其进行交互的智能合约
的安全性。
社区包括用户及钱包和交易所等应用程序。
工作组 Audit+, Wallet+, Core+
目标受众交易所、
社区及其他dApp项目方
计划类型开发、
设计
是否有MVP 是
MVP 成本 $95,500

1. 通过验证链上哈希与最新执行的审计的哈希值是否匹配，
交易者可以验证智能合约的安全性。
2. 通过集成基于良好的维护标准的API，
钱包在与智能合约交互时，
可以对智能合约提供批准签名
服务。
3. 通过钱包或推荐的前端页面，
用户可以便捷地查看相关智能合约的审计状态，
从而一目了然地确
认任意一个应用程序的安全性。
D) 交付成果
1. 针对链上合约推送新的审计报告：
允许安全审计员通过基金会或多签将最新完成的审计报告推
送到区块链上。每次审计应包含：
a. 加载合约的账户地址。
b. 已编译 WASM 执行本次审计的 SHA256 哈希。
c. 代码存储库URL。
d. 审计日期。
e. 审计员姓名。
f. 审计员电子邮件地址。
g. 若适用，
则提供证书链接。
h. 若公开，
则提供报告链接。
i. 审计结果：
通过或失败。
2. 自动追踪新智能合约联系人的 ABI 标准：
为了自动注册新的智能合约，
开发人员应在其 ABI 中列
出其合约的基本信息。（可能可以使用 ___comment : field）所需信息：
a. 部署时项目的安全联系信息。
b. 项目名称。
c. 代码存储库链接。
3. API标准：
创建API标准，
该标准在Github上展示并维护。
API JSON 示例如下
4. 前端: 对社区而言友好易用的Web前端及移动端平台，
该平台展示了dApps列表和基于API标准描
述的安全审计信息。

{
account: compcontract,
auditStatus: 0, // 0=not audited,1=auditing, 2=audited
timestamp: timestamp of latest audit,
org: {
company_name: dApp company,
website: https://www.company.io,
email: info@company.io,
code_repo: {
code_location: CODE URL
},
social: {
steemit: ,
twitter: company01,
facebook: ,
github: company01,
keybase: company01,
telegram: company01
}
},
audits: [{
timestamp: timestamp of audit,
organisation: {
name: Sentnl,
country: GB,
website: https://www.sentnl.io,
email: charles@sentnl.io,
},
name: name of smart contract,
hash: sha256,
report: link to report,
certificate: link to certificate,
result: passed
},
timestamp: timestamp of audit,
organisation: {
name: Slowmist,
country: CH,
website: https://www.slowmistio,
email: charles@slowmist.io,
},
name: name of smart contract,
hash: sha256,
report: link to report,
certificate: link to certificate,
result: passed
},
]
}

E) 投入水平
该计划包括3部分的独立工作：
链上数据、
API和列出所有已发布智能合约的前端。
.
• 前置条件和额外研究：
• 审计信息向链的推送需要由多签控制，
以确保审计员提供的信息在推送到区块链之前能够得
到验证。
尽管这并不是构建一个可用的最小可行产品所必需的，
但我们建议成立一个专门的
工作组来研究这个课题。
• 研究并定义API标准。
• 研究并定义ABI标准。
• 研究向社会提供此类信息的法律意义。
如果API消费者认定应用程序是安全的，
但这些应用
程序被盗用，
那这对API消费者来说意味着什么呢?尤其需要注意的是，
即使经过多次安全审
计，
也不能认为合约是完全安全的，
因此用户总会有赔钱的风险。
• 预估投入时长：
1280小时
• 预估支出：
95500 美元
• 所需专业人员：
• 智能合约开发人员- 280小时@$100 /小时(合计$28000)
• 前端设计师- 350小时@ $75 /小时(合计$26250)
• 全栈开发- 350小时@ $75 /小时(合计$26250)
• 项目经理- 300小时@$50 /小时(合计$15000)
F) 最小化可行产品
值得注意的是，
这里提出的最小化可行产品是基于一组非常小的智能合约。
为了将其运用于生产，
我
们首先需要建立一个可以从区块链和所有现行的安全审计中检索所有智能合约ABI的可靠方法。
1. 创建API标准
（全栈开发者~20小时）
a. 构建 Github 代码存储库
b. 定义一个JSON格式的API标准
2. 创建ABI标准
（智能合约开发者~20小时）
a. 定义开发者提供项目信息时需要遵守的 ABI标准

3. 构建使用ABI格式的测试合约且发布到区块链上
a. 使用ABI标准创建3个虚拟智能合约并发布到区块链上。
4. 创建链审计表并发布一定的测试数据
a. 创建一个区块链账户，
以及供审计者发布审计结果的链上表单。
b. 与安全工程师合作发布一定的安全审计结果。
5. 开发 API(全栈开发者~ 50 小时)
a. 建立数据库并定义数据库布局。
b. 建立API后端。
c. 创建API路径。
6. 编写可以从hyperion中获取数据的函数
（全栈开发者~100小时）
a. 编写可以从hyperion中获取ABI细节的函数，
可应用于模拟合约，
包括与之相关的模拟审计，
并发布至DB。
7. 开发并设计前端 (前端设计师 - 250 hrs,(全栈开发 - 100 小时)
a. 创建最小工作量的前端，
其可从API中检索数据。
b. 展示智能合约和其API中可获取的所有数据。
8. 创建 Docker镜像: (全栈开发 - 50 小时)
a. 将前端、
后端和数据库实例进行Docker镜像化处理，
便于快速开发和测试。
G) 最小化可行产品的进阶
最小可行产品的进阶不仅包含其所需的全部最小化可行产品组件，
也包含将产品进行投产的必要步
骤。
1. 历史解决方案:
a. 该解决方案将已完成安全审计的合约和智能合约ABI的合约增量合并到一起，
并保存至数据
库。
b. T该解决方案必须能在上一次流程的断点处停止并开始，
确保合约任何一个ABI信息没有被
漏掉。

H) 未来目标
1. 应该鼓励EOSIO合约审计者提供此类审计信息，
智能合约开发者也应该被要求将此类审计信息作
为合约的一部分，
因此可能需要针对该项举措投入一定教育和/或营销成本。
2. b. 提供一种重写/同步链上已审计智能合约列表和相关ABIs信息至API数据库的方法，
以防止仅
使用数据库造成数据缺失。
I) 参考材料
• Certik has a list of all their audits completed - https://www.certik.com
• https://github.com/ethereum-lists/contracts
• https://sourcify.dev
• https://developers.eos.io/welcome/v2.1/smart-contract-guides/understanding-ABI-files
• https://github.com/eosrio/bp-info-standard
2. 智能合约升级DAO
A) 痛点
我们都知道，
EOS合约可以在普通的EOS账户上部署。
默认情况下，
账户的所有者拥有更改合约的全
部权限。
这就造成了智能合约所有者和产品用户之间的信任问题。
用户如何知道合约所有者不会突然
将合约变更为未经测试和未经审计的版本，
或者更糟糕的情况下其会盗走智能合约中锁定的所有资
金。
我们需要找到一种构建信任的方法，
同时也允许开发者具有升级其智能合约的选择权。
因此，
我
们需要特定类型的多签DAO来管理智能合约的升级权限。
工作组 Audit+
目标受众 EOSIO社区
设计、
研究

B) 目标
建立一个或多个智能合约授权管理DAO，
专门管理EOS智能合约升级事务。
建立一个DAO智能合约，
以管理dApp合约账户的Owner和Active 私钥权限。
随着时间推移，
审计公司通过提供更全面的审计服务，
逐步积累开发者的更多信任感。
同样道理，
对
智能合约升级的DAO多签授权也应该成为一门生意，
该生意积累信任的途径应该是基于在处理智能
合约的验证和升级方面日积月累所攒起来的，
我们并不赞同由一个单一的实体来处理此授权业务。
由于考虑到参与这项计划涉及的利益攸关方，
还需要围绕这一主题展开更多研究，
但下面列出了此类
系统如何运作的示例。
DAO示例：
DAO XYZ提供智能合约升级设施。
该DAO由5个前21名的出块节点、
1个安全审计员和1个知名的
EOSIO twitter用户组成。
Jolly Defi加入了EOS主网，
并决定使用DAO XYZ提供的服务，
他们安装了由另一个外部安全审计员审
计的初始合约，
该合约在链上运行后，
该合约账户的Owner和Active私钥更新的必要条件是至少需要
6/8 MSIG多签。
MSIG多签构成：
1. 前21 节点
2. 前21 节点
3. 前21 节点
4. 前21 节点
5. 前21 节点
6. 安全审计人员
7. EOSIO 推特知名用户
8. Jolly Defi
（项目方）
DAO XYZ公司监视链上活动，
并通知Jolly Defi将 DAO XYZ添加为MSIG，
并给DAO XYZ发送必要的信
息：

a. 合约细节：
合约、
代码仓库、
编译器版本和安全审计链接。
b. 客户的详细信息：
应用网站，
代码仓库，
linkedin资料(如有)等...
DAO XYZ将校验安全审计的哈希值与加载在链上的哈希值是否匹配。
若一切检验无误，
则会将Jolly
Defi添加到他们的核准应用程序列表中。
随后，
任何使用Jolly Defi的用户，
都可以先行访问DAO XYZ并验证Jolly Defi是否的确由DAO XYZ管
理，
相关信息一目了然。
在理想情况下，
甚至应该将该信息整合至区块链浏览器中。
3个月后，
Jolly Defi想要升级他们的合约以提升性能。
随后他们将所有的相关信息发送至DAO XYZ进
行重新验证，
并发起一个MSIG来升级合约。
一旦DAO XYZ执行并通过了他们的校验流程，
其将签署并执行MSIG，
新合约被并部署到区块链上。
通过一种标准化的方法，
让对智能合约进行多签成为一种约定俗成的方法，
这样做的好处不仅可以降
低了开发者使用多重签名的门槛，
还提高了EOS用户对智能合约的信任。
D) 产出成果
建立一个EOSIO利益相关方同意的DAO 多签协议，
任何希望提供这类服务的DAO都可以基于该协议
来建立他们的业务。
E) 投入水平
• 预估时间: 400 小时
• 预估费用: 40000美元
• 研发人员要求:
• 研发员- 400 小时，
费用约为$100 /小时 (合计$40000)。
1. 深入研究这一主题并为这种类型的服务研发一个DAO协议(约花费350小时)。
a. 与多条EOSIO链上的利益相关者共同研究探讨这一主题。
2. 创建DAO多签协议文档
（约花费50小时）
。

F) 商业机会
这将是一项付费服务，
且服务提供商将形成竞争局面。
在未来，
DAO可以进行扩展，
比如在dApp中添加评级系统，
可以包括额外的校验，
如：
该合约是否提
供李嘉图合约来确定责任；
该合约是否是开源的，
并且可以由社区验证/审核。
G) 最小可行产品
建立一个负责合约源代码验证和合约升级审批的DAO。
H) 参考材料
无
3. 创建反洗钱平台
A)痛点
区块链作为一种新的技术平台，
具有开放性和匿名性的特点。
同时，
区块链上流通着大量有价值的
资产，
使其成为黑客攻击的主要目标之一。
根据慢雾记录，
迄今为止已知的547起黑客事件造成了
20,779,621,384美元的损失，
其中120起EOS黑客攻击事件导致大量EOS资产被盗。
黑客窃取资金后，
通常会将资金转移到交易所，
出售或交换成其他数字资产。
但交易所无法及时获得相关攻击事件的信
息，
未能阻断黑客进行交易，
使得交易所成为黑客洗钱的帮凶。
事实上，
这不仅仅是交易所要突破的困局，
在EOS生态系统中，
钱包、
浏览器和dApp都可能需要评估
链上的恶意行为和交易风险，
以减少恶意行为，
避免成为其洗钱帮凶，
同时遵守国际反腐败、
凡洗钱
和反恐融资条例。
由于EOS的TPS较高，
存储历史交易记录需要占用极大的存储空间，
且反洗钱平台
的核心技术之一就是分析历史交易，
因此建立这样的系统需要投入成本较高的硬件设备，
这也阻碍了
反洗钱平台的发展。

B) 目标
建立EOS原生的反洗钱系统，
从各种数据源(包括从暗网到全球数百个交易所的所有内容，
以及EOS社
区提供的情报)收集数据进行清洗和整合，
从庞大的数据采集中提取出准确的数据，
对账户进行身份
特征标记，
并实时监控资产的转移。
用户或合作伙伴可以通过接口检查账户或交易是否存在恶意行
为。
1. 为EOS治理提供数据支持，
减少链上的恶意行为，
如帮助被黑客攻击的项目方追回资金;
2. 帮助EOS交易所或钱包监控资金转移，
及时冻结非法资金;
3. 为监管机构提供执法依据，
分析洗钱行为，
推动EOS向合规方向发展。
D) 产出成果
1. 一个提供可视化图表以展示资产转移路径的网站：
用户在前端搜索框中输入帐号，
就可以通过图表形式查看资产转移状态。
2. 查询帐户标签的API接口：
API JSON格式示例:
{
lable: eos project exploit,
transactions: [
0x123456789...,
0x123456789...,
0x123456789...,
],
accounts: [
eoshacker...,
eoshacker...,
]
}

E) 投入水平
• 前置条件:
• 项目方需要有一定的区块链情报数据；
• 需要快速下载EOS历史节点数据;
• 估计工作时间：
1200小时
• 估计成本：
114000美元
• 所需专家:
• 前台设计师- 240小时@ $75 /小时(合计$18,000)
• 全栈工程师- 480小时@ $100 /小时(合计$48,000)
• 算法工程师-480小时@$100 /小时(合计$48,000)
1. 交易数据处理
（全栈工程师 - 240 小时）
a. 构建 EOS 全节点
（存储全部历史记录）
b. 将所有转账信息记录到特定的关系型数据库
2. 信息收集与处理
（全栈工程师 - 240 小时）
a. 收集已发生的黑客攻击事件中的相关账号
b. 尽可能多的收集可识别账户，
例如 dApp 和交易所账户
3. 开发账户关联算法
（算法工程师 - 480 小时）
a. 对目标账户的关联账户和资金关系进行排序
b. 创建数据查询接口
4. 设计网页 UI
（前端设计师 - 240 小时）
a. 显示帐号标记信息

G) 未来目标
1. 反洗钱平台应不断提高识别恶意行为的准确性，
提升系统的可靠性和可用性；
2. 鼓励EOS钱包、
浏览器、
交易所和其他平台使用反洗钱平台，
共同降低链上恶意行为的发生频
率。
H) 参考材料
• Etherscan Label Word Cloud: https://etherscan.io/labelcloud
• SlowMist AML: https://aml.slowmist.com/
• Chain Analysis: https://www.chainalysis.com/
A) 痛点
DeFi 协议现在动辄管理着数十亿美元资产，
其被攻击的潜在风险非常高，
安全问题日趋成为区块链
社区在构建智能合约时不可忽视的重点。
虽然安全审计和安全的操作行为是降低安全漏洞风险的关
键，
但光有这些是不够的。
开发并推出安全可靠的智能合约系统还缺少一个基础组件：
在开发过程中
集成安全性措施。
B) 目标
聘请有经验的开发者，
开发若干个常用的智能合约模板并开放给社区开发者。
工作组 Audit+
目标受众开发者
文档

通过使用或学习相关合约模板，
即便是没有经验的开发人员也可以掌握如何开发安全的智能合约，
从
而减少被黑客攻击的潜在风险。
D) 产出结果
创建合约模板并开源6个热门业务的实现代码，
且需要通过至少2家知名安全公司的安全审计。
E) 投入水平
• 前置条件：
• 调研智能合约在其他区块链生态系统中的实施进展。
• 预计小时数：
660 小时
• 估计成本：
170,000 美元
• 所需专家:
• 智能合约工程师 - 1000 小时 @ $100/小时 (合计$100000)
• 智能合约安全工程师 - 350 小时 @ $200/小时 (合计$70000)
F) 最小可行产品
1. 为典型的应用程序创建合约模板 ( 智能合约工程师 – 共1000小时 )。
a. 交换协议合约
b. 预言机协议合约
c. NFT 标准合约
d. 闪贷协议合约
e. 稳定币协议合约
f. 借贷协议合约
2. 对合约进行安全审计
（智能合约安全工程师 -共 350 小时）
。
a. T应对所有合约模板完成两次独立的安全审计

G) 未来目标
• 紧跟EOS生态发展的需求，
编写日趋丰富的开发模板。
H) 参考材料
• https://github.com/OpenZeppelin/openzeppelin-contracts
• https://github.com/open-web3-stack/open-runtime-module-library
• https://github.com/solana-labs/solana-program-library
A) 痛点
目前在 EOSIO 中，
缺乏一个定义明确的漏洞赏金计划，
无法有效激励黑客社区投入时间深入分析
EOSIO 代码库。
几乎所有Top区块链都有漏洞赏金，
其在奖金方面持续性保持着较高的竞争力，
从而可以源源不断的
吸引最优秀黑客社区的关注。
B) 目标
建立一个管理良好且定义明确的漏洞赏金计划，
提供可观的、
有诱惑力的奖励，
以招揽黑客社区中最
优秀的人才。
该计划应该有明确清晰且有效管理，
这样社区可以吸引并长期留住最优秀的黑客人才。
我们还需要一种将高危漏洞缺陷安全、
有效地传递至其他所有基于 EOSIO 链的方法，
以确保在高危
漏洞缺陷公开之前已及时更新修复。
工作组 Audit+
目标受众 Hacker community
计划类型 Development, Documentation

拥有一个得到充分管理的漏洞赏金平台可确保 EOSIO 能够吸引最优秀的黑客持续不断地评估
EOSIO 代码库。
该平台可以促进EOSIO整体更安全，
且积累越来越多的安全代码示例，
它不仅保护了
EOSIO 区块链本身，
还保护了在其上运行的智能合约。
当黑客发现的 EOSIO 漏洞，
同样也会导致其他
使用该函数库的其他软件出错时，
这还可以为EOSIO附带提供额外的正向营销宣传。
D) 产出成果
1. 定义明确的漏洞赏金。
a. 对漏洞的明确分类定义、
严重性范围及对应的赏金。
b. 关于构成一个bug的明确规则定义。
c. 提交bug的明确程序定义。
d. 明确定义的沟通机制，
确保基金会与黑客/安全机构之间及时沟通
2. 漏洞赏金计划的前端页面。
a. 对黑客/安全机构社区而言使用友好的 Web 前端 + 移动端平台，
支持展示有效的 EOSIO 漏
洞赏金、
排行榜、
赏金定义以及如何提交漏洞。
3. 沟通并传递高危漏洞错误的方法。
a. 研究与其他所有 EOSIO 链共同应对高危漏洞库的最佳策略。
E) 投入水平
为了使上述内容变为现实，
我们需要做的努力主要包括：
一个明确清晰的漏洞赏金计划；
一个吸引眼
球的网站；
良好的用户体验；
确保安全社区提交错误的方式便捷容易。
另一个需要深入研究的关键点
是如何将高危漏洞缺陷传达给其他所有的 EOSIO 链。
• 前置条件
• 基金会和其他 EOSIO 链需要对漏洞赏金级别和对应的赏金做出决策，
包含附加每个级别的
严重性。由于该计划适用于所有EOSIO链，
因此应分摊运行此服务的成本。
• 漏洞赏金网站还需要一个专门的 EOSIO 核心开发团队,主要负责评估收到的报告并确定对应
的漏洞赏金级别，
并在需要时协调安全升级工作
• 核心 EOSIO 开发人员需要一致同意管理漏洞赏金计划
• 漏洞赏金专款

• 除了 MVP 产品，
任何由安全社区发现的错误都可能产生新的报酬奖励，
因此难以直接有效
地预测未来可能产生的总报酬支出。
260 小时
• 估计成本：
16625 美元 + 漏洞赏金专款
• 全栈开发人员 - 105 小时 @ $75/小时 (合计$7875)
• 项目经理 - 5 小时 @ $ 50 /小时
（合计$250）
• 内容作家 - 50 小时 @ $15 /小时
（合计$750）
• 智能合约安全工程师 - 20 小时 @ $200/小时(合计$4000)
• 前端设计师 - 50 小时 @ $ 75 /小时
（合计$3750）
1. 设计前端
（前端设计师 - 50 小时）
a. 设计前端用户体验
2. 定义漏洞赏金
（内容编写者 - 50 小时，
智能合约安全工程师 20 小时）
a. 定义漏洞赏金级别和相关的赏金，
包括每个级别中构成漏洞的示例。
b. 定义漏洞对应的严重性级别。
3. 传达高危漏洞bug的方法
（项目经理 - 5 小时）
a. 与其他 EOSIO 链召开会议，
共同研究管理高危 EOSIO 漏洞错误的方法。
4. 开发前端
（全栈开发人员 - 75 小时）
a. 构建一个列有漏洞赏金计划相关的所有信息的独立页面。
b. 构建一个列有顶级漏洞赏金猎人的排行榜页面。
5. Docker：
a. 将前端打包镜像化，
便于部署和测试。
6. 提交漏洞的表单
a. 一个简洁的可用于提交漏洞的 Google 表单。

G) 未来目标
• 扩展漏洞赏金计划范围，
例如 EOSIO上的任何一个 dApp项目方均可以创建自己的迷你漏洞赏金
计划，
这将进一步鼓励安全研究人员积极反馈已发现的漏洞。
H) 参考材料
• https://ethereum.org/en/eth2/get-involved/bug-bounty/#rules
• https://guidovranken.com/notable-vulnerabilities-found-in-high-profile-software/
• https://twitter.com/etherchain_org/status/1431256423489495045?s=20
• https://www.telos.net/news/telos-evm-uncovers-ethereum-vulnerability
6. 开发自动化的安全审计工具
A) 困境
当前，
在 EOSIO 社区中并没有支持开发人员评估智能合约基础安全性的免费工具。当然，
既不开源
也不免费的工具确实是有的。
B) 目标
我们建议创建一个经常性维护的开源工具，
任何人均可采用该工具分析基于 EOSIO 编写的开源智能
合约，
且通过报告的形式展示该智能合约在应对当前众所周知的漏洞时所采取的应对措施情况。
该工具应该免费、
易安装且能够快速生成结果。
该工具生成的结果应该是一目了然并其附带的参考资料可以帮助开发人员了解如何解决这些问题。
理想情况下，
这应该与另一个提议
（编写 EOSIO智能合约的常见安全漏洞列表）
相关联。
如此一来可
以确保形成一个共同的知识库，
以防止文档之间相互割裂。
工作组 Audit+
建议类型开发、
文档

拥有这样的工具可以促进开发人员自查代码，
在开发者社区形成如何避免常见安全缺陷的知识沉淀。
从长远来看，
这促进开发人员和安全社区在实现围绕 EOSIO 安全方面实现自驱的长期进步。
D) 产出成果
7. 自动化的安全审计工具。
a. 基于 Python 语言构建的具有模块化特性的安全审计工具，
便于其他人贡献
（译者：
诸如优
化、
丰富该工具的功能等）
。
b. 该工具应提供有关如何解决问题的报告和参考知识库。
c. 该工具应易于安装且安装过程记录在案。
d. 该工具应分析智能合约并标记众所周知的可被黑客利用的漏洞所在的具体代码行位置。
E) 付出水平
这项提议所涉及的工作量将远高于其他提议措施，
因为它需要进行一些初步计划以便最大化发挥该
工具的效用。
• 前置条件
• 应进一步研究如何创建一个具有模块化特性的安全审计工具，
以允许外部贡献和持续开发。
• 理想情况下，
应在本项目之前先完成编写EOSIO 智能合约常见安全漏洞列表的计划
约1550 小时
• 估计成本：
152500 美元
• Python 开发人员 - 1050 小时 @ $50/小时 (合计$52500)

1. A自动化的安全审计工具
（Python 开发人员 - 1000 小时，
智能合约安全工程师 500 小时）
a. 基于 Python 语言构建一个基础的安全审计工具
b. 该工具应该是模块化的，
以允许外部贡献
（新增的安全检查代码）
c. 易上手的安装说明文档。
d. 该工具应建立在Git 上。
2. 报告
（Python 开发人员 - 50 小时）
a. 该工具应提供基本报告，
且报告中详细标明了所引用的常见安全漏洞列表链接。
G) 参考材料
• https://klevoya.com/inspect/index.html
• https://github.com/crytic/slither
• https://github.com/ConsenSys/mythril
7. 建立编写EOSIO智能合约时易犯安全缺陷列表
A) 痛点
在编写智能合约时，
只要访问并充分掌握共享知识库内的知识，
很容易避免最常见的安全陷阱。但目
前我们没有关于此类缺陷的系列文档。
这是其他Top区块链中极其常见的功能，
我们认为极有必要效仿
EOSIO 中提供了一些示例：
:
工作组 Audit+
建议类型文档

• https://github.com/slowmist/eos-smart-contract-security-best-practices/blob/master/
README_EN.md
• https://cc32d9.medium.com/eosio-contract-security-cookbook-20210527-69797efe9c96
B) 目标
开发人员在编写智能合约时可以参考的常见安全缺陷列表
（经常性更新）
。
此类类型文档的好处是让开发人员在开发他们的智能合约时可以想起 EOSIO 上最新发生的漏洞威
胁，
从而为开发者提供双重保障。
D) 产出物
1. 编写 EOSIO 智能合约时的常见安全漏洞列表。
E) 投入水平
建议提供一个文档或 Wiki，
其列出了编写 EOSIO 智能合约时最常见的安全漏洞，
可通过版本跟踪来
积极维护。
• 前置条件
• 无
455 小时
• 估计成本：
54000 美元
• 内容创作人员 - 200 小时 @ $15 /小时
（合计3000 美元）

1. 常见的安全缺陷：
（智能合约安全工程师 - 250 小时，
内容作者 - 150 小时）
a. 列出 10 个已知的常见安全缺陷，
其中包括：
I. 攻击类型的描述。
II. 出现该错误的示例源代码。
III. 可能导致的漏洞。
IV. 任何现实生活中已发生的漏洞代码示例
（如果有的话）
。
2. 在 GIT 等分布式版本控制的系统上创建。（智能合约安全工程师 - 5 小时，
内容作者 - 50 小
时）
a. 创建 Git 存储库以实现版本控制。
b. 创建文本编辑器，
从而像Wiki一样可编辑。
G) 参考材料
• https://blog.neodyme.io/posts/solana_common_pitfalls
• https://github.com/sigp/solidity-security-blog
• https://cc32d9.medium.com/eosio-contract-security-cookbook-20210527-69797efe9c96
• https://github.com/slowmist/eos-smart-contract-security-best-practices/blob/master/
README_EN.md

五. 致基金会的最佳行动方案提议清单
这里提议的4项举措是基于我们做出的全部研究成果:不仅仅是 EOSIO 社区所必需的，
也是其他区块
链社区所必需的举措。对于任何一个想要从安全性维度满足区块链安全所需条件的区块链项目而
言，
提议1-3是实现这一目标的基石。
提议 4 是在以太坊上运用的相对新颖的举措。 EOSIO 采纳这一举措将是非常有优势的，
因为EOSIO
核心技术具有几个显著的优势，
使其更易采用这种类型的解决方案。尽管这是一项艰巨的任务，
并且
需要所有工作组中的多个利益攸关者共同去决定最佳方法，
但采用这些举措将对实现系统更深层次
的信任带来深远影响。
1. 编写 EOSIO 智能合约时常见的安全缺陷列表
理由：
这是一个非常轻松的胜利，
也是一个良好的开端，
可以帮助引导开发者社区创建健壮且安全的智能合
约。它还可以作为未来工具
（例如自动化安全审计工具）
的基础。
成本预测：
MVP成本：
• 初始 MVP ，
22500美元
持续成本:
• 每年22500 美元以保障列表持续更新
本提议需要持续的成本投入，
从而确保列表不断更新。由于列表是开源的，
因此部分更新工作将来
自开发者社区，
但基金会应每年聘用专门的承包商
（频率为一年1-2次）
，
以确保该列表持续更新。

理由：
对于开发者社区而言，
本项提议与提议1
（常见安全缺陷列表）
一样也是重要组成部分，
本提议有助于
培养编写安全的智能合约的最佳实践。
成本预测：
MVP成本：
• 初始 MVP， 152,500 美元
持续费用：
• 每年 50,000 美元，
以确保该工具持续最新
理想情况下，
该工具由开发者社区持续最新，
但基金会应每年聘请专门的承包商
（频率为一年1-2次）
，
以确保该工具持续同步最新的安全问题。
理由：
基于安全角度考量，
为了确保 EOSIO
软件的核心代码是健壮的，
我们需要吸引外部的安全社区来持续测试 EOSIO代码库。
成本预测：
MVP成本：
• 初始 MVP， 16,625 美元。
持续费用：
• 未知
漏洞赏金计划的管理需要核心 EOSIO 开发人员达成共识，
这需要 B1 和基金会之间再展开其他单独
的讨论，
因此我们无法提供平台持续管理所需的成本预测。

除了管理之外，
还有对发现的安全漏洞进行奖励的成本，
这些漏洞的发现同样无法预测，
因此这项成
本也是未知的。
4. 开源的安全审计 API 和平台
理由：
构建一个强大的安全审计平台
（几乎其他区块链没有）
，
这将使得用户在与 EOSIO
dApps 交互时感觉到非常安心，
使EOS走在安全性前沿。
成本预测：
MVP成本：
• 初始 MVP ，
54,750 美元。
持续费用：
• 成本：
每年 50,000 美元，
以确保平台持续最新
平台构建完成后大部分工作将完成，
但为了紧跟EOSIO 生态系统持续发展的脚步，
应不断更新安全审
计API和平台。

六. 附录
ABI
（应用程序二进制接口）
：
智能合约中两个程序模块之间的接口。
API
（应用程序编程接口）
：
一种允许程序间相互通信的软件中介。
漏洞赏金计划: 漏洞赏金计划是由不同网站、
组织和软件开发人员提供的交易。
在交易中，
上报者通
过提供相关网站、
软件等存在的缺陷，
尤其是与安全漏洞及漏洞有关的错误，
获得相应的认可和报
酬。
DAO
（去中心化自治组织）
：
有时称为去中心化自治团体，
是一个将规则编码成透明的计算机程序的
组织，
由组织成员管理而不受中心化政府的影响。
dApps
（去中心化应用）
： (dApps)是存在并运行在EOSIO区块链上的数字应用或程序。
DeFi：
基于去中心化的金融应用程序。
模糊测试：
模糊测试是一种自动化的软件测试技术，
通过向dApp或计算机程序提供无效的、
非预期
的或随机的输入值，
然后监视dApp或程序出现的异常情况，
如崩溃、
断言失败或潜在的内存泄漏。
软件开发工具包(SDK)：
是一个可安装包中的软件开发工具集合，
便于开发程序
WebAssembly (WASM)：
一种实现Web应用程序高效运行的可移植二进制代码格式。

Audit+ Blue Paper (Chinese)

Recommended

Recommended

More Related Content

Similar to Audit+ Blue Paper (Chinese)

Similar to Audit+ Blue Paper (Chinese) (20)

More from ZackGall1

More from ZackGall1 (7)

Audit+ Blue Paper (Chinese)