本文翻译自BM文章，原文见：https://medium.com/@bytemaster/debunking-claimed-vulnerability-in-eosio-smart-contract-system-9fa1ca2a6428
为了在中文社区更好地传播，IMEOS将文章翻译成中文，欢迎大家到原文留言与BM讨论。
就像最近在 Ethereum 发现的 “batchOverflow” 漏洞一样，有传言称 EOSIO 很容易受到同样的漏洞攻击，这种漏洞使得许多 ERC-20 token 在 Ethereum 变得瘫痪。 成都链安科技公司(链安科技)及其研究平台 VaaS (安全验证服务)的团队成功地证明了 EOSIO 是图灵完备的，可以包含任何逻辑，甚至包括了 “batchOverflow” 漏洞的bug逻辑。
这个问题并不是他们所呈现的安全漏洞，而是糟糕的代码结果。 一个智能合约平台无法阻止开发人员犯错误。 这些错误并不是底层平台的安全漏洞。
尽管如此，对于那些聪明到能够采用好的惯例的开发人员来说，可以选择的选项有很大的不同。 其中一个选项是实现”智能整数”封装，该封装可以自动检查这些类型的溢出，而不会给代码添加任何额外的噪音。
例如，可以使用 boost multiprecision 定义的 checked_int64_t。 一个简单的 typedef 可以将不安全代码转换为安全代码，如果出现溢出，该代码将失败。 C + + 模板和运算符重载的结合意味着使用安全数学就像使用不安全的数学一样无缝。
任何迫使开发人员总是使用“安全数学”的平台也会限制开发人员在需要溢出的情况下的灵活性和/或性能。
事实上，有许多情况发生，那就是在标准类型下防止溢出是远远不够的。 如果你想有一个安全的整型变量来保持所有的值在一个定义的范围内呢？ 用c ++模板你可以创建一个有界的整数类型。 用简单的语言如Solidity来实现相同的、在编译时就得以检查的代码并不容易。
比较平台
如果想要对平台进行比较，应该考虑选择采用开发人员可采用的具备安全性和可读性工具，并且在最优方法的基础上接纳并比较这些平台。 在稳定性上，你不得不使用不可读的函数来封装所有的数学函数。 由于无法使用+ / — *内建的运算符而导致可读性的损失与缺少边界检查一样严重。
另一个要考虑的因素是各种安全措施的运行时性能。 C ++编译器通常可以编译时间检查，优化并将许多数学检查内联到最小程序中。 像Solidity的类似检查, 它强制使用函数调用并且由于开发人员工具的不成熟性，与经过各种艰难检测的C ++工具相比，缺乏内联代码的能力。
升级代码的能力
在我最近关于 “batchOverflow” 漏洞的推文中，我提出了开发人员并不完美并且代码需要更新的问题。 一个好的平台会使升级在默认的情况下变得容易，而不是困难。 用户应该强制性地明确地将合约标记为不可逆的。 此外，即使是由其创建者标记为不可逆的合约，也应该可以由社区进行修改而不需要硬分叉。
不负责任的报告
链安科技团队和其他报道这个问题的博客是构建了一个草率的论点来针对EOSIO。他们不负责任地报道的结果是误导了那些不了解技术的人。作为一个行业我们必需要能够精确地理解安全漏洞（平台不像所设计的那样运行）、用户错误（开发者没有正确地使用平台）和基础平台设计漏洞（没有给开发者保护工具的平台）这几个概念的区别。
EOSIO的设计旨在为开发者提供最强健的工具箱，以实现编写高性能、高品质、低漏洞的合约，并且让平台和合约实现优于他人的尽善尽美的自我修复。
此处要提一句，在平台发布漏洞当天，IMEOS也发文解释了(如下)。
并特别注明：该智能合约漏洞不属于EOS本身的问题，是开发者自身的疏忽导致。BEC漏洞也不是ETH智能合约本身的问题，而且开发者疏忽。