虽然以太坊本身的技术没有问题，不代表在其之上写出的智能合约没有bug，事实上，已经发生过很多次了。如果写出健壮的智能合约成为了一个研究方向，没有bug的程序是不可能存在的，所有健壮性策略的目标都是紧急规避和减小损失，而不是100%安全。
智能合约一些常见的bug
overrun bug
假设一个合约是这么写的
contract money {
mapping(address=>uint) book
...
function withDraw() {
if(book[msg.sender] > 0){
if(msg.sender.call.value(book[msg.sender])()) {
book[msg.sender] = 0;
}
}
}
}
然后攻击者是这么写的
contract attack {
uint times;
function() {
if(times == 0) {
money.withDraw();
}
}
}
然后如果attack主动去call一次money.withDraw()，看看会发生什么？
transaction refuse
假设我们写了一个拍卖合约，每当当前出价最高者被超过时，就将他所出的份额返还，该怎么写？
如果写成：
...
if(被超过){
lastwinner.send(lastbid);
}
而某一个bidder的code是这样的：
contract bidder {
function() {
throw;
}
}
ok,如果这个bidder不幸的成为了暂时的winner，你就会发现，没有任何一个人能出价超过它了，因为所有的超过他的出价交易都会被cancel掉
智能合约安全策略
停止开关
这个策略是用一个Emergency的modifier，紧急情况下可以停止某些智能合约功能。code如下：
modifiler stopInEmergency {if (!stopped) _ }
modifier onlyInEmergency {if(stopped) _ }
contract XX {
function normal() stopInEmergency {}
function destroy() onlyInEmergency {}
}
损失最小化
损失最小化策略主要是在合约的各个功能点处设立保护屏障，比如如果你在写一个涉及转账的合约，那么在转账功能里就可以设置最大额度，如果超过这个额度，就需要合约管理员去approve，或者延迟发送。
bug奖券
这个是一个很奇妙的策略，就是让你的智能合约可以很容易被别人部署，然后一旦有bug发现，就会给予发现者一点奖励。
先检查，再生效，最后才交互
任何一个函数，首先需要检查各种条件并尽早报错，然后让函数应有功能生效，最后才是去与外界接口交互。
因为如果不提前生效改变自己的状态，在与外界交互时它们就可能通过进一步触发用合约不正确的状态去执行一些操作。
pull over push
假设我们写了一个拍卖合约，每当当前出价最高者被超过时，就将他所出的份额返还，该怎么写？
如果写成：
...
if(被超过){
lastwinner.send(lastbid);
}
而某一个bidder的code是这样的：
contract bidder {
function() {
throw;
}
}
ok,如果这个bidder不幸的成为了暂时的winner，你就会发现，没有任何一个人能出价超过它了，因为所有的超过他的出价交易都会被cancel掉。
原因是我们的函数里有对send的依赖，而这个是不安全的，正确的做法是出价被超过时，仅仅将他的出价打个标记，让出价者自己去call某一个withdraw函数把自己的份额拿回来。
QQ群：654894791
微信公众号： 94ETH
头条号: 周期与泡沫
