以太坊和区块链应用程序建设，是具有一定高度实验性的。因此，随着新的bug和安全风险的发现以及最新的实践开发，您应该期待区块链安全环境应有不断的变化。 因此，遵循本文档中的安全实践将会是您作为智能合约开发人员将要做的安全工作的开始。

智能合约编程需要的工程思维方式与您惯常的思维方式不同。 失败的代价可能很高，并且要做出修正非常困难，这使其在某种程度上与Web或移动开发相比，更类似于硬件编程或金融服务编程。因此，已知抵御漏洞还远远不够。相反，你更需要学习一种新的发展哲学：

为失败做准备

任何优秀的智能合约代码都会有错误。因此，您的代码必须能够优雅地响应bug和漏洞

· 出问题时暂停智能合约（“断路器circuit breaker”）
· 金额风险管理（限制利率，最大使用率）
· 为修复bug和改进提供有效的升级路径

谨慎发布

在正式发布完整版本之前，最好多遍检查代码。

· 彻底测试智能合约，并在发现新的攻击漏洞时再次进行测试。
· 从Alpha Testnet版本开始提供漏洞赏金。
· 分阶段推出，在每个阶段增加代码漏洞测试。

保持智能合约简单

复杂性增加了bug的可能性。

· 确保简单合约逻辑。
· 模块化代码以减少智能合约功能。
· 尽可能使用已知的编程的工具或代码（例如不要滚动自己的随机数生成器）。
· 尽可能保持智能合约的架构清晰。

保持版本更新

使用“安全通知”部分中列出的资源跟踪新的安全发展。

· 一旦发现任何新的bug，请检查您的智能合约。
· 尽快升级到工具或库的最新版本。
· 采用最新的安全技术。

清楚区块链功能

尽管您的许多编程经验都与以太坊编程相关，但仍有一些陷阱需要注意。

· 对于外部智能合约调用要格外小心，这可能会引发恶意代码或恶意更改控制流程。
· 清楚你的公共功能是对外开放的，可能会被恶意地以任意调用。任何人都可以查看智能合约中的私人数据。
· 牢记gas成本和区块链gas限制。
· 请注意，时间戳在区块链上是不精确的，矿工可以在几秒钟的时间内影响交易的执行时间。
· 随机性在区块链上并非无关紧要，大多数随机数生成方法在区块链上都是可改的。

基本的权衡:简单性与复杂性案例

在评估智能合约系统的结构和安全性时，需要考虑多方面因素。任何智能合约系统的一般建议是在这些基本权衡找到适当的平衡。

从软件工程角度出发，理想的智能合约系统是模块化的，可以重用代码而不是重复代码，并支持可升级组件。来自安全架构偏见的理想智能合约系统可能会共享这种思想，尤其是在更复杂的智能合约系统的情况下。

但是，在某些重要例外情况下，安全性和软件工程最佳实践可能会不一致。在每种情况下，都可以通过确定沿智能合约系统维度的最佳属性组合来获得适当的平衡，例如：

· 刚性与可升级
· 整体化与模块化
· 复制与重用

刚性与可升级

尽管包括该资源在内的多种资源都强调可延展性特征，例如可停止，可升级或可修改模式，但可延展性与安全性之间存在根本的权衡。

根据定义，可延展性模式会增加复杂性和潜在的攻击面。在智能合约系统在预定义的有限时间段内执行非常有限的功能集的情况下，例如在无治理的有限时间范围内的代币销售合约系统中，简单性在复杂性方面特别有效。

整体化与模块化

完整的独立智能合约使所有代码在本地都是可识别和可读的。尽管很少有人高度关注以整体形式存在的智能合约系统，但对于数据和流的极端局部性（例如在优化代码审查效率的情况下）存在争议。

与此处考虑的其他折衷方法一样，安全最佳实践趋向于从简单的短期智能合约中脱离软件工程最佳实践，而在更复杂的永久智能合约系统中趋向于软件工程最佳实践。

复制与重用

从软件工程的角度来看，智能合约系统希望在合理的情况下最大程度地提高重用率。在Solidity中有许多重用智能合约代码的方法。通常使用经过验证的，以前拥有的，已拥有的智能合约是实现代码重用的最安全方法。

如果没有自有的先前部署的智能合约，通常会依赖代码复制。诸如OpenZeppelin的Solidity Library之类的工作试图提供一种模式，以使安全代码可以重复使用而无需重复。任何智能合约安全分析都必须包括任何以前未建立过与目标智能合约系统中的风险资金相对应的信任级别的重用代码。

接下来半个月将是以太坊智能合约安全实操的课程。欢迎大家持续关注，同时区块链研究实验室官网将会提供以太坊solidity在线编程功能。