AdEx网络团队要求我们审计他们建立的合同，以运行其分散的广告交易合同。
1.1 URI
被审计的代码位于https://github.com/AdExBlockchain/adex-core
1.2 承诺
被审计代码的提交哈希值。
e724a6dc3499b8fc64ed692a1ff3c9b03458faf4
1.3 审计的文件
contracts/ADXExchange.sol
contracts/ADXRegistry.sol
审计反馈
2.1 总结
这次审计是由Modular, Inc进行的，目的是帮助AdEx识别其广告注册和广告交易合同中的潜在安全漏洞。对两份合同及其附带的测试进行了审计。
总的来说，这些人群销售合同写得相当好，使用了可信的方法和安全的编码风格。使用Zeppelin Ownable、Drainable、ERC20和SafeMath合约是一个明智的选择，减少了潜在的安全问题。
在这些合约中没有发现任何关键问题。一些影响可用性和防止滥用的小问题被发现并修正。还有一些小的造型和文件问题建议，这可能是主观的。
2.2 细节
2.2.1 关键问题
关键问题可以被定义为那些会导致逻辑不能像宣传的那样运作的项目。例如，由于缺乏授权检查而可能被独立方利用的逻辑，由于非边界检查而导致资金被截留的代码，或直接被破坏的逻辑。
在这次审计中没有发现关键问题。
2.2.2 主要问题
主要问题可以定义为那些会让任何一方拥有比预期更多的杠杆作用的项目，但不像关键问题那样严重。例如，可能被所有者意外利用的逻辑，或者会让其他受信任的参与者拥有优势。
ADXExchange.sol
描述
第135、136、192和193行。从ADX注册表合同中调用通用获取器函数，以达到检索和验证的双重目的
建议
创建明确的函数，有目的的实现这个目标。这在最初的发布中似乎没有意义，然而，未来的代码更新可能会导致不可预见的破坏性变化，没有明确的函数将ADX Exchange需要的信息与ADX注册表联系起来。
2.2.3 其他信息
ADXRegistry.sol
描述
`var`和`uint`的使用是一致的，这不允许对变量和类型有明确的定义。
建议
隐含的类型定义让代码审查员不得不做出假设。无论是对于用户、内部开发更新，还是审计人员，明确地定义类型而不是依赖`var`或`uint`，可以使未来的代码审查更加容易。审核人员不需要做任何假设，可以建立清晰的联系。
描述
函数和它们的参数没有得到一致的记录。
建议
有一个一致的方法来记录函数和变量是良好的编码实践。这取决于团队选择最适合他们的方法，但Ethereum Natspec格式是一个好的开始。
描述
函数的参数没有按照一致的顺序排列。
建议
对于类似的函数，良好的编码实践是总是以相同的相对顺序排列它们的参数。例如，在 register() 的第60行，name参数是第一个参数，而在 registerItem 的第86行，name是第四个参数。对齐参数的顺序可以使用户更容易与合同互动而不犯错。
描述
第22行和第23行：计数和项目名称没有描述性。
建议
在合同中以易于理解的方式命名变量是一种良好的编码实践。为计数和项目添加一个更具描述性的名称会使代码更易读。像 itemCounts 或 itemsByType 这样的名字就足够了。
描述
结构中的一些成员变量不是完全必要的，比如name和meta。
建议
通常的做法是，在以太坊智能合约中只包括合约运行所严格需要的信息、功能和变量。除非这些变量是合约运行所需要的，否则删除它们可能是一个很好的选择，以减少Gas成本，为用户提供更简单的接口，并减少代码中需要核算的变量数量。这些额外的信息可以通过对链上ID的引用保留在链下。
描述
第60行：`register()`函数没有检查`_sig`。`registerItem()'函数中的`_type'也是如此。
建议
Consider whether or not this is purposeful and if `_sig` should be required and/or `_type < enum.length`
描述
第86行："registerItem() "函数没有 "外部 "范围定义，因为 "register() "函数有这样的定义。
建议
对于这两个合同，`register()`函数是唯一明确说明范围的非getter函数。代码应该是一致的，范围定义也显示了目的。考虑为所有函数说明适当的范围级别。
ADXExchange.sol
描述
第118行：没有检查构造函数的参数是否有效
建议
所有潜在的输入和错误都应该被考虑和检查，即使是在构造函数中。检查两个参数是否为0。
描述
第98行："onlyBidAceptee() "的拼写不正确，也没有准确表示关系
建议
改为 "onlyBidAccepter() "以纠正这个问题
2.3 结论
总之，这些合同写得相当好，在安全方面没有任何关键问题。测试可以扩大一些，对质量有更客观的保证，但不是绝对必要的。通过建议的修改，合同的行为应该是一致的，对参与者来说更容易理解和正确使用。
Modular为打算部署在EVM网络上的软件提供智能合约服务和安全审查，此外还为Ethereum社区的开源项目工作。我们还测试、记录和部署可重复使用的代码到区块链上，并通过我们的代码库（https://github.com/Modular-Network/ethereum-libraries）提高安全性和可用性。最后，我们也喜欢教育非营利组织、学校和其他社区成员关于区块链技术的应用。
欲了解更多信息：majoolr.io,contact@majoolr.io