Ultrain 技术团队核心成员近期在阅读 EOS chainbase 开源代码时，发现其底层实现存在可导致 EOS 全网宕机隐患的致命安全漏洞，并立即将问题详细描述及修复办法提交至 EOS 团队。近日，EOS 团队已正式将修复提交 EOS 代码主分支，并对于 Ultrain @raymondnuaa 表示多次致谢！

公链 EOS 采用 chainbase 内存数据库存储世界状态，包括链上所有账号详情、部署的所有智能合约以及所有历史交易形成的状态修改等内容。chainbase 的安全性与稳定性是保证公链 EOS 稳定运行的重中之重。

EOS 该安全漏洞由 chainbase 对数据库回滚操作的错误处理顺序引发。chainbase 内存数据库底层有 removed、created、modified 三个 stack 来存储区块内交易对数据库对象所进行的删除、创建、修改操作，如果该区块未能成功添加到区块链主链，则需要对该区块内所有交易对内存数据库做的所有修改进行回滚。EOS 对三个 stack 的原有回滚处理顺序为：modified，created，removed，在该处理顺序下，如果将数据库某个已有对象 A 的键值修改，并创建一个新的对象 B 采用前述对象 A 的原有键值，那么在进行回滚时，会先尝试将对象 A 修改过的数值恢复，此时会产生键值冲突（数据库此时存在对象 B 具有相同键值），导致底层库进入死循环状态。一旦进入该状态，EOS 节点则无法正常继续生产区块。若恶意攻击者构造触发该状态的交易广播至全网执行（e.g. 通过 deferred trx），则 EOS 全网存在宕机隐患。

发现问题后，EOS 开发团队按 @raymondnuaa 建议将 stack 处理顺序修改为 created，modified，removed，可正常处理前述场景。此外，@raymondnuaa 在问题描述中还详细描述了另一个更加复杂的两个对象键值交换的场景，并指出仅靠调整三个 stack 的处理顺序无法解决问题。EOS 在此次修改中也增加了大量注释，明确了 chainbase 内对象的使用需求限制，指出 chainbase 的特定字段不能在 modifier 中进行修改（should not be changed within a chainbase modifier lambda），并对 deferred_transaction 的 modify 处理做了相应修改。

公链是促进区块链行业繁荣发展的一个重要角色，相信有如 Ultrain 这样致力于提升基础设施安全的公链存在，整个行业将会更加健康有序发展。

详情链接：https://github.com/EOSIO/eos/pull/7266
https://github.com/EOSIO/chainbase/pull/44