关于 Edgeware 锁仓合约的拒绝服务漏洞，我们注意到 Edgeware 被爆了个严重的漏洞，这个漏洞已经修复，对已经锁仓的用户及修复后继续锁仓的用户不存在影响，且目前的情况来看，由于漏洞是负责任披露，应该是没有造成实际影响。
但这个漏洞为什么说严重？我简单科普下。
近期，Edgeware 这个 Polkadot 生态知名的链项目，因为独创的 ILO(Initial Lock-up Offering) 机制，其中一种方式是允许参与方通过锁仓 ETH 来获取更多的 Edgeware 数字货币激励，已经处理了超过 9 亿美元的 ETH 并锁定了超过 2.9 亿美元，一度很火热。
图 1
如“图 1”所示，每个参与者都可以通过 Edgeware 发布在以太坊上的 Lockdrop 合约进行锁仓获取激励操作，成功后会生成一份属于自己权限控制下的独立 Lock 合约，这份合约本身是安全的（至少我们还未发现已知潜在风险）。但有趣的是：漏洞出现在 Lock 合约生成的那一刻。
图 2
大家注意“图 2”的 lock 函数，有一段关键代码：
assert(address(lockAddr).balance == msg.value);
这段代码做了强制判断：属于参与者的 Lock 合约的金额必须等于参与者锁仓时发送的金额，如果不等于，意味着 lock 失败，这个失败会导致参与者的 Lock 合约“瘫痪”而形成“拒绝服务”，直接后果就是：假如攻击持续着，Edgeware 这个 Lockdrop 机制将不再可用。但这个漏洞对参与者的资金无影响。那么，什么情况下会导致“address(lockAddr).balance 不等于 msg.value”？攻击者如果能提前推测出参与者的 Lock 合约地址就行（这在以太坊黄皮书里有明确介绍），此时攻击者只需提前往参与者的 Lock 合约地址随便转点 ETH 就好。Edgeware 针对这个漏洞的修复代码也很简单，见“图 3”，将 Lockdrop 合约的：
图 3
assert(address(lockAddr).balance == msg.value);
改为：
assert(address(lockAddr).balance >= msg.value);
就这样。是的，Lockdrop 合约重新发布了一份新的。
存在漏洞的 Lockdrop 合约：
https://etherscan.io/address/0x1b75b90e60070d37cfa9d87affd124bb345bf70a#contracts
修复后的 Lockdrop 合约：
https://etherscan.io/address/0xFEC6F679e32D45E22736aD09dFdF6E3368704e31#contracts
智能合约真是一点错误都不行。相关参考：
https://medium.com/@nmcl/gridlock-a-smart-contract-bug-73b8310608a9
https://blog.edgewa.re/a-denial-of-service-bug-in-the-edgeware-lockdrop
https://ethereum.github.io/yellowpaper/paper.pdf
