智能合约solidity_在Solidity智能合约中使用枚举之前，请三思而后行

智能合约solidity

假设您正在编写Solidity智能合约&＃xff0c;并且其属性之一可以描述为类型或状态 。 换句话说&＃xff0c;从有限的一组选项中得到的东西。 您立即对自己说&＃xff1a; “好极了&＃xff0c;我只将枚举类型用于此状态变量。” 一方面&＃xff0c;这种方法具有一些好处&＃xff0c;例如增加了可读性。 另一方面&＃xff0c;它可以轻松地带您走上一条可能导致问题的棘手的道路。

你在说什么&＃xff1f;

好吧&＃xff0c;如果枚举成员仅封装在一个合同中&＃xff0c;而在其他文件中从未提及&＃xff0c;则一切正常。 但是&＃xff0c;DApp通常由相互关联的多个合同组成。 当相同的枚举出现在我正在谈论的问题&＃xff1a;

1. 出现在多个合同中&＃xff0c; 并且
2. 在DApp生命周期中进行了修改。

例如&＃xff0c;您有2个合同。 第一种是用于存储非常重要信息的存储 。 您还声明了带有枚举定义的接口以引用该接口。

每个用户的记录都由两个可能的选项的枚举表示&＃xff1a;StateA和StateB。 setState函数能够更改用户的状态。 最终用户还应该与之交互另一个合同&＃xff08;为简单起见&＃xff0c;我在存储合同中省略了访问控制修饰符&＃xff09;。

然后将这些合同部署到区块链。

一切都好&＃xff1a;

您调用changeStateA或changeStateB&＃xff0c;并且存储合同的数据将通过其自己的setState函数进行相应的修改。 但是有一天&＃xff0c;您意识到对于某些全新功能&＃xff0c;您需要一个全新的状态选项。 您称它为StateC&＃xff08;哇&＃xff01;真叫&＃xff01;&＃xff09;。 首先&＃xff0c;通过在IStorage中添加新的枚举成员来修改源代码…

…以及StorageUser的新方法。

此外&＃xff0c;作为负责任的开发人员&＃xff0c;您编写调用新方法的测试&＃xff0c;并且它们报告成功。

您的计划是仅重新部署StorageUser合同&＃xff0c;并且您不想重新部署Storage &＃xff0c;因为映射形式有很多重要数据&＃xff0c;这些数据很难迁移。 因此&＃xff0c;使用当前的Storage作为其构造函数参数重新部署StorageUser 。 您调用新的changeStateC函数...&＃xff0c;它将失败。

等等&＃xff0c;什么&＃xff1f; 为什么&＃xff1f; 测试还可以。

故障原因

您会看到&＃xff0c;更新后的StorageUser知道RecordState枚举的3个成员&＃xff0c;但是旧的Storage没有关于新StateC选项的线索。 它无法将setState函数参数StateC转换为其枚举版本&＃xff0c;因此失败。

而且&＃xff0c;您的测试可能欺骗了您&＃xff0c;因为它们使用了两个合同的更新版本。
实际上&＃xff0c;您甚至可以在官方文档中阅读有关此问题的警告。

从整数进行显式转换会在运行时检查该值是否位于枚举范围内&＃xff0c;否则会导致失败的断言。

可悲的事实是&＃xff0c;有时您只是忽略了这些事情&＃xff0c;自己碰到了这些问题。

经验教训

首先&＃xff0c;在上述情况下&＃xff0c;最好用普通整数替换枚举。 是的&＃xff0c;它们看起来不太好&＃xff0c;但是生成的结构更可靠且可扩展。

其次&＃xff0c;不要抛弃使用枚举字段的整个想法。 如果这样的领域只在一个合同之内&＃xff0c;那绝对是安全的。 如果可以确保在进行修改的情况下完全重新部署使用枚举的所有合同&＃xff0c;这也是安全的。 请记住&＃xff0c;当将枚举首先从IStorage导入到StorageUser合同时&＃xff0c;出现了问题&＃xff0c;并且在修改初始成员后仅重新部署了后者。

只是不要忘记&＃xff0c;如果您真的想在合同中使用枚举 &＃xff0c;最好三思而后行。

尝试一下

该示例的源代码已上传到GitHub 。 我已经在测试文件中重现了有问题的行为。 随时检查它并进行实验。

学分

1. 人的图象在森林里。 Pexels的Dewa Prabawa 摄
2. 小猫的图象。 Pexels的Vadim B 摄影

翻译自: https://hackernoon.com/beware-the-solidity-enums-9v1qa31b2

智能合约solidity