作者：RayXiao,SallyGu,IOSG Ventures
本文为IOSG原创内容，仅做行业学习交流之用，不构成任何投资参考。如需引用，请注明来源，转载请联系IOSG团队获取授权及转载须知。
前言：
在9月底Paradigm官宣完成了区块链安全项目Blowfish的领投又一次引起了大家对智能合约安全分析领域的广泛关注。但其实Paradigm团队在此之前就已经在智能合约安全测试方向做了很多实践，在今年3月Paradigm CTO Georgios公布了他们开发的Foundry智能合约测试套件（Runtime Verification团队也是重要的贡献者），如今区块链安全分析也在朝着更细致的分工方向发展。
从最近几个月融资趋势和市场反应来看，一级市场资本目前对注重安全信息时效性、风险覆盖度、技术偏轻量级的安全监测、防火墙领域有浓厚的兴趣（这和以往大部分资本投入在审计领域大有不同）。
根据CertiK和SlowMist的相关报告，仅2022年第一季度和第二季度因安全攻击问题crypto资产损失就高达20亿美元。在第二季度单闪电贷攻击就导致了总计3亿美元的资产损失。而本月更是成为了有史以来黑客活动最大的一个月，两周内仅针对DeFi协议的攻击已超过12次，被盗金额超7亿美元。
来源:https://twitter.com/chainalysis/status/1580312145451180032?s=20&t=QfqOMqMKjHd3EtX_0O-QjA
如果我们把链上智能合约从开发>>部署至区块链网络>>运行看成是一个完整生命周期的话，针对智能合约的安全分析分为：针对合约部署前（在区块链网络正式上线运行前）的分析、合约部署后的分析，这大致涵盖了：测试、审计、监测三大类目，每个类目下面又有各种类型的分析方式和相应的工具（如下图）。PS：智能合约的审计覆盖面会从合约部署前到部署后（合约升级审计）
1. 智能合约部署前的安全分析：测试+审计
1.1 测试（Testing）
合约测试是开发者和审计者需要花费最多精力的工作，这与传统开发者不同。因为区块链不可篡改的特性，一旦智能合约部署到EVM虚拟机上就难以变更，因此安全分析、弥补安全漏洞的工作大部分花费在“事前分析”——对智能合约部署前的安全测试。
在接受正式审计前，合约开发者/审计者需要对合约的代码进行一些基础性的测试，初期测试的覆盖率越高越能避免一些简单的bug进入正式审计阶段（一般一份智能合约达到85%-90%的代码被测试覆盖是合理水平；针对核心模块的覆盖率需要在95%以上）。
常见的基础性的测试有单元测试（聚焦于单个函数的测试）和集成测试（确保各部分代码组合起来也能正常运行）。这个阶段常用的工具有Hardhat、Truffle test framework等，常见的测试内容包括：状态检查、事件触发、交易重置、函数计算、完全功能测试。
来源: https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d
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）
来源: “Bad Proofs in Formal Verification” by Certora team at Devcon Bogata
从实际规模化运用来说，形式化验证相对传统的测试方案在规模化运用上相对较慢。大部分的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，无法挂单等。
来源: GoPlus
-
前端恶意代码 (攻击者会将恶意代码植入交易所等网站的前端，如用户浏览器的标签管理系统，从而通过这串恶意代码生成错误的批准，允许用户资产被转移至攻击者的地址)
案例：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://www.coindesk.com/business/2022/09/30/paradigm-leads-118m-funding-round-into-web3-firewall-blowfish/
https://ethereum.org/en/developers/docs/smart-contracts/testing/
https://docs.openzeppelin.com/learn/writing-automated-tests
https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297
https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d
感谢：Xinshu Dong, Runtime Verification team, Hexens team对此文的帮助和意见
