必备九条措施 保障智能合约安全性

尽管区块链行业的发展日趋成熟，但是智能合约的开发仍是一个相对较新的领域。因此，为了应对新的漏洞和安全危机，以及满足开发新的最佳实践的需要，我们应该不断完善安全性方面的问题。学习最佳实践只是智能合约开发者在安全性方面踏出的第一步。

智能合约编程需要一种不同于传统的工程思维。智能合约失败的代价很高，更新迭代需要较大工程量，这使得它在某些方面更类似于硬件编程或金融服务编程，而不是web或者移动端开发。因此，仅仅防御已知的风险是远远不够的，还需要掌握新的开发理念。

准备应急措施

任何重要的合约都会出现故障。因此，开发者必须做好充足的准备，以便及时应对漏洞。

出现故障时暂停合约 (“断路器”)。

管理风险资金的数量 (限制流量，最大化利用率)。

准备有效的升级路径以修复和改进bug。

防患未然

最好是在完整的产品发布之前发现bug。

全面测试合约，并在发现新的攻击向量时添加相应测试。

alpha测试网版本发布之后，提供bug赏金。

分阶段推出，每个阶段更新功能并添加新测试。

保持智能合约的简洁性

复杂性会提高出现故障的概率。

确保合约逻辑简单。

模块化代码以使合约和函数保持较小。

请尽可能使用既有工具或代码 (例如不要使用自己的随机数生成器)。

在保证清晰度的前提下再考虑性能。

只在系统中需要去中心化的部分使用区块链技术。

保持更新

跟进新的安全性措施。

检查智能合约，以最快的速度定位新漏洞。

尽快升级到任何工具或库的最新版本。

采用可能有效的保障安全性的新技术。

了解EVM的特性

尽管开发者对以太坊编程较熟悉，但仍需要注意一些陷阱。

要特别小心外部合约调用，该过程可能会执行恶意代码并改变控制流 (control flow)。

要明白，开发者的公共函数是公开的，可能会被恶意调用，调用顺序也可能是任意的。任何人都可以查看智能合同中的隐私数据。

注意gas成本和区块gas限制。

注意，区块链上的时间戳是不精确的：矿工可以在几秒内影响交易执行的时间。

随机性是区块链上一个重要的特性，大多数产生随机数的方法在区块链上是具有博弈性的。

基本权衡因素

在评估智能合约系统的结构和安全性时，需要考虑多种基本的权衡。对于所有智能合约系统的普遍建议是，在这些权衡之间找到平衡点。

从软件工程的角度来看，理想的智能合约系统是模块化的，即重用代码而不是复制代码，以及支持可升级的组件。而从安全架构的角度来看，理想的智能合约系统可能同样会使用这种模式，尤其是面对更为复杂的智能合约系统。

然而，当安全性和软件工程最佳实践出现不一致时，也会有一些例外情况发生。而在每种情况下，可通过选择合约系统上的最佳性能组合来达到平衡，例如:

固定版本vs.可升级

整块化vs.模块化

复制vs.重用

固定版本vs.可升级

当多个资源 (包括此资源) 强调自身的延伸性时 (比如可中断的、可升级的或可修改的模式)，那么就需要在延伸性和安全性之间找到一个平衡点。

延伸性增加了复杂性和潜在的受攻击性。如果智能合约系统在预先规定的有限时间内能够完成的功能非常有限，那么这时简洁性比复杂性要有效得多，例如，无治理的限时代币发售合约系统。

整块化vs.模块化

独立的整块化合约允许信息在本地识别和读取。虽然整块化合约一般不被重视，但对于数据和流的极端本地化存在争议，例如代码审计的效率优化。

与本文考虑的其他因素一样，在简单的短期合约中，安全性最佳实践趋向于与软件工程最佳实践相悖；而在更复杂的永久合约系统中，两者趋于相一致。

复制vs.重用

从软件工程的角度来看，智能合约系统希望能够在需要时最大化重用功能。在Solidity语言中，有许多重用合约代码的方法。实现代码重用的最安全的方式通常是：使用自己之前经过验证和部署的合约。

如果之前部署的合约无法使用，开发者通常就需要依靠复制功能了。OpenZeppelin的Solidity库尝试提供一些模式，使得安全代码可以在无需复制的情况下被重用。任何合约安全分析都必须将目标智能合约系统中还没有与风险资金建立相当信任级别的重用代码包含在内。

现如今，在以太坊上创建应用软件无疑是最令软件工程师激动的前沿领域，但这需要持续不断的威胁建模 (threat modeling)、安全审计，还需要做好周全计划以应对故障发生。