联盟链中的安全: 智能合约典型漏洞浅析

漏洞往往会重复出现

我们可以对智能合约的典型漏洞进行分类：

• 变量/函数命名混合：FirePonzi，Rupixi
• 不应公开的公开数据：公共RNG种
• 重入（A调用B调用A)
• gas限制

已经提出了许多关于智能合约安全的解决方案，从更好的开发环境到更好的编程语言再到形式验证和符号执行，研究人员已经开始开发这种工具。我的个人看法是：智能合约安全性的进步必将是分层的，增量的，并且必定依赖于纵深防御。会有更多的错误，我们将学习更多的课程；不会有任何魔术技术能够解决所有问题。

该基本结论的理由如下。智能合约被盗或丢失的所有实例-实际上，智能合约被盗或丢失的定义本质上是关于实现与意图之间的差异。如果在给定的情况下，实施和意图是同一回事，那么“盗窃”的任何实例实际上都是捐赠，而“损失”的任何实例都是自愿烧钱，在经济上等同于向ETH的比例捐赠通货紧缩使代币持有者社区这导致了下一个挑战：意图从根本上讲是复杂的。

友好的AI社区已将这一事实背后的哲学最好地加以规范化，该社区的名称为“价值的复杂性”和“价值的脆弱性”。命题很简单：我们作为人类有很多价值，也有非常复杂的价值-如此复杂以至于我们自己无法完全表达它们，而任何试图不可避免地包含一些未发现的极端案例的尝试。该概念对AI研究的实用性很重要，因为超级智能的AI实际上会遍历每个角落，包括我们发现的直觉到我们甚至都没有想到的角落，以最大化其目标。告诉一个超级智能的人工智能来治疗癌症，它将通过分子生物学中的一些适度复杂的调整而获得99.99％的治疗方法，但是它很快就会意识到，通过核战争和人类灭绝引发人类灭绝，它可以将这一比例提高到100％。 /或生物大流行。告诉它在不杀死人类的情况下治愈癌症，这只会迫使所有人冻结自己，理由是它并不是从技术上杀死人，因为如果愿意的话，它可以唤醒人类，但不会。依此类推。

在智能合约土地上，情况类似。我们相信我们重视“公平”之类的东西，但是很难定义公平甚至意味着什么。您可能要说诸如“某人不可能仅从DAO窃取10000 ETH”之类的事情，但是如果对于给定的提款交易，DAO确实批准了转让，因为接收者提供了有价值的服务该怎么办？但是，如果转移获得了批准，我们怎么知道决定这种转移的机制没有被博弈论的弱点所欺骗？什么是博弈论漏洞？那“分裂”呢？在基于区块链的市场中，前行呢？如果给定的合同指定了可以收取费用的“所有者”，那么如果任何人成为所有者的能力实际上是规则的一部分，又会增加乐趣呢？

所有这些都不是对形式验证，类型理论，怪异的编程语言等专家的打击。聪明的人已经知道并赞赏这些问题。但是，它确实表明，要实现的目标存在根本障碍，“公平”并不是在一个定理中可以用数学方式证明的东西-在某些情况下，公平要求的集合是如此之长和复杂，以至于您拥有想知道这组声明本身是否有错误。

缓解之路

也就是说，在很多领域中，意图和实现之间的差异可以大大减小。一种类别是尝试采用通用模式并对它们进行硬编码：例如，可以通过将owner设为只能在构造函数中初始化为等于msg.sender并可能在transferOwnership函数中进行转移的关键字来避免Rubixi错误。另一类是尝试创建尽可能多的标准化中级组件。例如，我们可能希望阻止每个娱乐场创建自己的随机数生成器，而是将人们引导到RANDAO。

但是，更重要的解决方案类别包括减轻EVM执行环境的特定和不直观。 其中包括：gas限制，重入（负责DAO和Maker ETH合同）和调用堆栈限制。 可以完全禁止重入（即一次只允许每个合同的一个执行实例），但这可能会引入新形式的不直观性，因此可能需要更好的解决方案。

但是，gas限制并没有消失。 因此，唯一的解决方案可能是在开发环境本身内部。 如果没有数据的情况下合同的gas消耗量不能少于2300，则编译器应发出警告。 如果功能无法在安全的gas范围内终止，他们还应该发出警告。 变量名可能带有颜色（例如，基于名称哈希的前三个字节的RGB），或者，如果两个变量名彼此之间过于接近，则可能会发出启发式警告。

另外，有些编码模式比其他的更危险，尽管不应该禁止使用它们，但是应该清楚地突出显示它们，要求开发人员证明使用它们的合理性。 一个特别涉及的例子如下。 很明显，有两种类型的调用操作是安全的。 第一个是包含2300gas的发送（前提是我们接受这样的规范，即在数据为空的情况下，接收方有责任不消耗超过2300gas）。 第二个是对您信任的合约的调用，该合约本身已经确定是安全的（请注意，此定义禁止重入，因为在证明A安全之前，您必须先证明A安全）。

解决方案的第三类是纵深防御。为了防止损失（而不是盗窃），一个例子是鼓励所有非永久性的合约都具有到期日，在此之后，所有者可以代表合同采取任意行动；这样，只有在（i）合同搞砸了，同时（ii）所有者失踪或不诚实时，损失才有可能发生。受信任的多重签名“所有者”可能会出现以缓解（ii）。可以通过增加等待时间来缓解盗窃。 DAO问题的范围得到了极大的缓解，这恰好是因为DAO子被锁定了28天。 MakerDAO中的一项建议功能是在任何治理变更生效之前创建一个延迟，从而使token持有者对变更时间出售其token不满意；这也是一个好方法。

形式验证可以放在最上面。一个简单的用例是一种证明终止的方法，可以大大减轻与gas有关的问题。另一个用例是证明特定的属性-例如，“如果所有参与者合谋，他们可以在所有情况下取出钱”，或“如果您将代币A发送到此合同，则可以保证获得代币的数量B您想要或能够全额退还自己的款项”。或“该合同适合于Solidity的受限制子集，这使得重新进入，gas问题和调用堆栈问题无法实现”。

尽管到目前为止，所有关注点都与意外错误有关，但恶意错误是一个额外的关注点。对于MakerDAO分散交易所没有漏洞让他们拿走所有资金的情况。但是智能合约安全模型的整个目的是提供足够强大的保证，即使情况并非如此，也可以生存下去，以便实体它们之间没有很好的联系并且建立起来不足以使人们自动信任他们。因此，任何检查或突出显示不仅应存在于开发环境的级别，还应存在于块浏览器和其他工具的级别，在这些级别，独立的观察者可以验证源代码。

检查清单

社区可以采取的检查步骤是：

• 承担创建一个高级开发环境以及一个高级块/源代码浏览器的项目，该项目包括其中的一些功能
• 尽可能多地标准化组件
• 承担尝试不同智能合约编程语言以及形式验证和符号执行工具的项目
• 讨论可减少意外或故意错误风险的编码标准，EIP，对Solidity的更改等
• 如果您正在开发价值数百万美元的智能合约应用程序，请考虑与安全研究人员联系并与他们合作，将您的项目用作各种验证工具的测试用例