从最近几个月融资趋势和市场反应来看，一级市场资本目前对注重安全信息时效性、风险覆盖度、技术偏轻量级的安全监测、防火墙领域有浓厚的兴趣
作者：Ray Xiao, Sally Gu, IOSG Ventures
封面：Photo by Shubham's Web3 on Unsplash
本文为 IOSG 原创内容，仅做行业学习交流之用，不构成任何投资参考。如需引用，请注明来源，转载请联系 IOSG 团队获取授权及转载须知。
前言：
在 9 月底 Paradigm 官宣完成了区块链安全项目 Blowfish 的领投又一次引起了大家对智能合约安全分析领域的广泛关注。但其实 Paradigm 团队在此之前就已经在智能合约安全测试方向做了很多实践，在今年 3 月 Paradigm CTO Georgios 公布了他们开发的 Foundry 智能合约测试套件（Runtime Verification 团队也是重要的贡献者），如今区块链安全分析也在朝着更细致的分工方向发展。
从最近几个月融资趋势和市场反应来看，一级市场资本目前对注重安全信息时效性、风险覆盖度、技术偏轻量级的安全监测、防火墙领域有浓厚的兴趣（这和以往大部分资本投入在审计领域大有不同）。
根据 CertiK 和 SlowMist 的相关报告，仅 2022 年第一季度和第二季度因安全攻击问题 crypto 资产损失就高达 20 亿美元。在第二季度单闪电贷攻击就导致了总计 3 亿美元的资产损失。而本月更是成为了有史以来黑客活动最大的一个月，两周内仅针对 DeFi 协议的攻击已超过 12 次，被盗金额超 7 亿美元。
如果我们把链上智能合约从开发>> 部署至区块链网络>> 运行看成是一个完整生命周期的话，针对智能合约的安全分析分为：针对合约部署前（在区块链网络正式上线运行前）的分析、合约部署后的分析，这大致涵盖了：测试、审计、监测三大类目，每个类目下面又有各种类型的分析方式和相应的工具（如下图）。PS：智能合约的审计覆盖面会从合约部署前到部署后（合约升级审计）
1. 智能合约部署前的安全分析：测试+审计
1.1 测试（Testing）
合约测试是开发者和审计者需要花费最多精力的工作，这与传统开发者不同。因为区块链不可篡改的特性，一旦智能合约部署到 EVM 虚拟机上就难以变更，因此安全分析、弥补安全漏洞的工作大部分花费在 “事前分析”——对智能合约部署前的安全测试。
在接受正式审计前，合约开发者/审计者需要对合约的代码进行一些基础性的测试，初期测试的覆盖率越高越能避免一些简单的 bug 进入正式审计阶段（一般一份智能合约达到 85%-90% 的代码被测试覆盖是合理水平；针对核心模块的覆盖率需要在 95% 以上）。
常见的基础性的测试有单元测试（聚焦于单个函数的测试）和集成测试（确保各部分代码组合起来也能正常运行）。这个阶段常用的工具有 Hardhat、Truffle test framework 等，常见的测试内容包括：状态检查、事件触发、交易重置、函数计算、完全功能测试。
1.2 审计 Auditing
“测试可以有效地发现程序存在的缺陷，但是它却无法证明程序不存在缺陷。”—— Edsger Wybe Dijkstra（计算机科学家、1972 年图灵奖获得者）
根据 Ethereum 官方文档的定义，审计是对智能合约每一行源代码的细节评估，攻击者的思维方式来绘制智能合约中可能的攻击向量，以发现可能的故障点、安全漏洞和不良的开发实践。审计阶段大致包含：静态分析、动态分析（模糊测试 Fuzzing test、符号执行 symbolic execution）、人工分析、形式化验证。正如上图所说的 Dijkstra，单靠测试无法完全相信程序没有故障，审计、形式化验证更多的是想更加靠近程序不存在缺陷这一目标。
金钱成本
根据智能合约安全公司 Hacken 的数据，智能合约审计服务的行业的平均成本在 5000 美元到 30000 美元之间（中小型项目）。对于大型项目，成本有时可以达到 50 万美元甚至更高。智能合约审计的成本直接取决于代码复杂性和商定的工作范围。影响价格的其他因素包括紧急程度、智能合约的大小（有多少行代码）、完成流程所需的工程小时数、与项目相关的文档的可用性等因素。
时间成本
初始审计平均需要 2 到 14 天，这也具体取决于项目的复杂性、智能合约规模和紧迫性。对于大型项目或协议，初始审核可能需要长达 1 个月的时间。初始审核完成后，客户会收到有关要引入哪些修改的建议。
人力成本
根据 IOSG 在区块链形式化验证领域的领投项目 Runtime Verification 的反馈，审计的人力成本取决于协议的复杂性。对于大部分拥有资深行业经验和学术经验的头部安全审计公司来说，理解 crypto 客户项目的商业逻辑和 token economics 基本没有太大难度，一般两个专业的工程师大概花费 1~2 个星期就可以完成初始步骤。
但是接下来的部分会取决于客户的具体需求。有的客户只需要对被审计项目的基本业务逻辑进行人工审计（查看他们的代码并手动审查它是否符合所需的业务逻辑），这是最便宜的服务。有的客户希望对业务逻辑和 token economics 进行建模然后手工进行数学证明以确保某些重要结果成立，例如安全性、活性、一致性等。有些大客户像 MakerDAO、以太坊基金会等则希望更进一步，对代码进行形式化验证 (Formal Verification)。
这里关于形式化验证再多说一句，形式化验证是用数学方法去验证程序的正确性——程序的实现与程序员的意图相符，最终证明项目的系统是 Bug Free 的。或者换句话说，形式化验证像是一种更全面的 “testing”，它理论上会包含所有可能的输入和状态，这是 testing 无法做到的（如下图例子所示转账合约中有 overflow bug，如果用 testing 需要测试者输入一个极大的值才能找出，但是形式化验证者会通过 “total amount of the token = sum of the balance of all addresses” 的数学逻辑来找出 overflow bug）
从实际规模化运用来说，形式化验证相对传统的测试方案在规模化运用上相对较慢。大部分的 crypto 项目来说，完成智能合约审计之后就已经足够，从成本投入和潜在效益来说对小型项目来说还不是必需品 (或者说证明程序是 bug-free 的代价还比较高），核心原因是形式化验证需要专业的形式化人才参与，因为对项目代码创建形式化规范（formal specification) 是非常复杂的事情，需要涵盖合约代码的属性，并定义合约在不同情况下的行为方式，这些需要专业的人才参与。（感兴趣的读者详见我们之前写的《为什么我们领投 Runtime Verification》https://mp.weixin.qq.com/s/VWVgn4k9k0XqbM-O7-TVXg）
智能合约审计当下仍然是一个 labour intensive 的行业，并且对人才的技术要求较高。目前虽然市面上有十几款比较流行的审计工具（大多由主流安全审计公司或者学术研究人员开发)，但是这些审计工具开发的目的是发现比较普遍的漏洞比如：transaction order dependency, random number, timestamp, callstack depth, Reentrancy, dangerous delegate call 等等）。因此，仅仅依赖这些工具去完成审计工作比较困难，可能会错过许多和业务逻辑相关的漏洞。通常审核智能合约需要使用自动化工具+手动代码审查相结合的方式，并且根据客户的智能合约业务逻辑、Token 模型的不同需要 case by case 的人工审查。
智能合约安全分析和审计往往是在验证程序的正确性，也就是程序的实现与程序员的意图相符。因为程序的 bug，其实都是由程序的实现与程序员的意图之间有区别导致的。我们之前在分享我们投资 Runtime Verification 一文中提及的形式语义学的其实就是能让开发者的开发意图（即 “语义”）和实现（即编程语言的 “语法”）精确相符的语言框架，从而减少 bug 的出现。
在智能合约安全审计领域目前虽然市面上工具也不少，且大多开源，但是拿来真正做到成功商业化的寥寥无几，这其中根本原因我们后面也会分析，总之目前还是依赖于安全服务提供商自己的自动化工具+人工阅读每一行代码或建模，基本无法通过直接卖自动化审计工具拿到规模化商业收入。
PS: 根据我们最近领投的 Hexens 反馈，初期对于一些静态分析的测试 Slither 和 MythX 是他们常用的开源工具，虽然结果并不能让他们非常满意。对于更高级别的测试，他们主要用 fuzzers 如 Echidna、Forge+built in fuzzer
2. 智能合约部署后的安全分析——监测（Monitoring）
目前 10 种最常见的区块链网络安全攻击里 Scam 出现频率最高，且给用户直接造成资产损失最高。根据 Peckshield 的数据，在 2021 年 crypto 因为各类 scams 造成的链上经济损失达 120 亿美金，比黑客直接攻击造成的损失要高 6.7 倍。
常见的 scam 攻击：
- 网络钓鱼（常见的网络钓鱼技巧是发送电子邮件/网站要求用户重置密码/恢复他们的帐户。一旦用户登录这些虚假网站，他们就会窃取私钥）案例：Alice 登录某交易所后链接 MetaMask 钱包，收到弹窗提示钱包故障，需要助记词恢复，恢复后钱包内资产被全部盗走。
- 冒名/冒充（自称是某些 dapps/机构的员工或代表的人可能会通过电子邮件、电话或社交媒体联系用户。他们将通过发送虚假的免费铸币/空投网站从用户那里窃取资金。或者通过冒充行为来操纵受害者以提取资金或敏感数据）案例：乌克兰政府接受加密货币捐赠并宣布空投 NFT，冒名者伪装成乌克兰政府发出假 token 空投进行诈骗。
- Discord 管理身份劫持（攻击者通过控制受到社区信任的管理员的机器人发布虚假公告，诈骗链接，或欺骗受害者放弃他们的加密货币或 NFT）案例：黑客通过控制蓝筹 NFT 如 Bored Ape Yacht Club 等 discord 官方服务器，批量对成员发送错误链接，用户点击后资产会被不可逆地盗取
- BGP 劫持（通过谎称拥有实际上并不能控制的 IP 前缀，并将之添加到互联网 BGP 路由器中的路由表进行，攻击者可以实现对该 IP 地址流量的劫持，在这种情况下用户一旦尝试登录就会被重新导向至攻击者设好的陷阱地址）案例：Celer 遭受 BGP 劫持攻击，波及 32 名用户和 23.5 万美元的损失（2022.08）
- 代码后门&陷阱（攻击者通过隐藏在正常程序中的一段具有特殊功能的恶意代码，如具备破坏和删除文件、发送密码、记录键盘和 DDoS 攻击等特殊功能的后门程序以窃取用户个人信息）案例：Bob 在某网站 mint 了一个 NFT，两天后发现不翼而飞。因为攻击者在 NFT 代码植入了某些特征，可以授权他人进行 NFT 交易或可以破坏他人的 NFT，无法挂单等。
- 前端恶意代码 (攻击者会将恶意代码植入交易所等网站的前端，如用户浏览器的标签管理系统，从而通过这串恶意代码生成错误的批准，允许用户资产被转移至攻击者的地址) 案例：KyberSwap 因为黑客安插的前端恶意损失 256 万美金（2022.09）
常见的工具：
相比于智能合约安全审计，提供 monitor&firewall 服务涉及的业务内容更为庞杂和细密。
Focus 在合约部署前以及合约部署后升级的智能合约代码安全审计，往往通过各类型的测试（静态分析、动态分析）输入一系列的值来看合约的输出值及状态是否正常运行。比如针对一个常见的链上转账逻辑（如下图），常见的测试人员会做：transfer zero ether, transfer all the ether, transfer slightly more than all the ether, transfer the largest possible amount of ether, transfer an account's value to itself 等事情来看合约是否可以如能做到程序员预期该做的事情和实现的结果。
Focus 在事中安全分析的 monitor/firewall 服务，要处理的问题更繁杂。并且目前看下来这类项目提供的安全服务更注重广度（涵盖尽可能多的有问题的链上资产合约、最新的涉嫌诈骗行为的地址合约钓鱼网址等等），它们相对比合约审计的安全服务更轻量级。涉及许多跟检查代码正确性之外的安全风险，比如各类诈骗、钓鱼相关的攻击。而监测这些漏洞除了需要依赖合约解析能力之外，还需要不断更新可疑地址、可疑合约逻辑、可疑资产清单等数据的风险数据库。
通过我们和最近行业内从业人员的交流，发现不同的 Monitor 服务定位其实也各有不同，比如 GoPlus 更加注重提供数据 API 服务给项目方甚至是一些注重前端的防火墙；Harpie、Blowfish 更注重提供前端服务，当用户执行一个交易行为、或者完成一次授权之前模拟这个交易以发现问题阻止用户有安全风险的交易；Tenderly 则更注重开发者的需求，为智能合约开发者提供运行监测等服务。当然目前这个领域还比较新，尽管像 Opensea 这样的大型交易平台已经和一些项目进行实质的商业合作，但是我们认为未来商业化的路径还是不太明晰同时会遇到的同业竞争会不小（因为相较于代码审计技术上的门槛会低一些）。
3. 智能合约安全分析工具的商业发展机遇和挑战
1）目前来看行业内的许多人认为 monitoring&firewall 跟 security auditing 之间的商业边界还较为模糊（现在看都属于 2B 的服务，客户大部分是各类 crypto 项目方），理论上来说由在区块链安全领域深耕多年的专业安全审计公司直接提供 monitoring service，甚至开拓 B2C, 2C 化的终端用户直接收益的产品更符合商业发展逻辑。但是由于 monitoring 赛道刚刚起步，收费模式和盈利模型尚不明确（目前看到是 2B 抽取服务费或者项目的交易手续费分成），如果市场回暖安全审计市场会仍然处于供> 需，订单做不完的状态可能无暇顾及这个新兴市场，这个时间窗口会是给新出现的专门做 monitor/firewall 的公司一个很好的机会。
2）智能合约审计的自动化工具目前市面上已经有很多，常见的有十几种大多开源。这个方向通过卖工具来收费的商业模式尚未跑通，核心原因是：1）黑客和安全防御者的博弈关系是 an arms race and the attack is always a moving target，魔高一尺 道高一丈。安全工具一旦推出，黑客就会尝试绕过它，开发出新的攻击形式。所以安全工具只能不断迭代更新将攻击门槛提高；2) 大部分工具使用门槛不低，会使用专业安全分析工具产品的人少，因此限制了市场规模 (虽然 Runtime Verification 有在推给普通开发者使用的 Firefly, ConsenSys Dilligence 也有 MythX); 3) 安全分析工具只能覆盖主流的漏洞，而根据协议业务逻辑的经济模型的不同客户主观更希望审计团队人工提供定制化的服务。
团队主观也希望一个受市场 authorized 的审计公司提供较深度定制化审计服务并且盖戳。因此，提供 monitoring service 会是专业安全团队切入可规模化产品的一个很好的机会点。
3）为 defi 项目方，DAO 或个人服务的 insurance 业务可能会成为下一片蓝海。考虑到目前市场对于黑客直接盗取私钥等攻击方法并没有良好的防范或解决方案，以风险规避和资产保障为目的的保险业务很可能在未来会受到更多的青睐。当然考虑到加密资产本身的复杂性和合规方面的多重不确定性，underwriter 往往会承受更大的风险，因而在解决这一问题之前，insurance 产业的发展可预见的，仍然将面临一定的瓶颈。期待随着整体加密资产体量的上升和更多传统机构用户的进入，insurance 业务能在下一个周期来临之前能够实现更多制度性的完善。
Reference:
https://www.paradigm.xyz/2022/03/foundry-02
https://ethereum.org/en/developers/docs/smart-contracts/testing/
https://docs.openzeppelin.com/learn/writing-automated-tests
https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d
感谢：Xinshu Dong, Runtime Verification team, Hexens team 对此文的帮助和意见
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
