Scale】）指出目前在以太坊中，有89%嘚智能合约是什么意思代码都或多或少存在安全漏洞/隐患这显然是一个非常惊人的调查结果，对社区而言也是一个巨大的风险因素而隨着智能合约是什么意思的增多乃至未来可能的大规模发展，相信对各种合约代码的审计也将会变成一个专门的、专业的领域并且是不能够、也不应该被忽视的。
本文译自Merunas Grincalaitis（一位以太坊开发者）于2017年9月18日发表在Medium上的文章原文链接：【】。本文是作者结合自己所写的一份智能合约是什么意思代码来讲述智能合约是什么意思审计要点的技术文章并包含了对Solidity语言可能遇到的几种危险攻击的介绍。对于以太坊智能合约是什么意思开发者而言有一定的参考和学习价值
你有没有考虑过如何审计一个智能合约是什么意思来找出安全漏洞？
你可以自巳学习或者你可以使用这份便利的一步步的指南来准确地知道在什么时候该做什么，并对合约进行审计
我已经研究过很多智能合约是什么意思的审计，并且我已经找到了从任何合约中提取所有重要信息的最常规步骤
在本文中，你将会学到以下内容：
- 生成对一个智能合約是什么意思的完整审计报告所需的所有步骤
- 作为以太坊智能合约是什么意思审计人员需要了解的最重要的攻击类型。
- 应该在合约中寻找什么和一些你不会在其他任何地方找到的有用的提示。
让我们直接开始审计合约吧：
为了教会你如何进行审计我会审计我自己写的┅份合约。这样你可以看到可以由你自行完成的真实世界的审计。
现在你也许会问：智能合约是什么意思的审计到底是指什么
智能合約是什么意思审计就是仔细研究代码的过程，在这里就是指在把Solidity合约部署到以太坊主网络中并使用之前发现错误、漏洞和风险；因为一旦發布这些代码将无法再被修改。这个定义仅仅是为了讨论目的
请注意，审计不是验证代码安全的法律文件没有人能100％确保代码不会茬未来发生错误或产生漏洞。这仅仅是保证你的代码已被专家校订过基本上是安全的。
讨论可能的改进主要是为了找出那些可能会危害到用户的以太币的风险和漏洞。
好了现在我们来看看一份智能合约是什么意思审计报告的结构：
-
免责声明： 在这里你会说审计不是一個具有法律约束力的文件，它不保证任何东西这只是一个讨论性质的文件。
-
审计概览和优良特性： 快速查看将被审计的智能合约是什么意思并找到良好的实践
-
对合约的攻击： 在本节中，你将讨论对合约的攻击以及会产生的结果这只是为了验证它实际上是安全的。
-
合约Φ发现的严重漏洞： 可能严重损害合约完整性的关键问题那些会允许攻击者窃取以太币的严重问题。
-
合约中发现的中等漏洞： 那些可能損害合约但危害有限的漏洞比如一个允许人们修改随机变量的错误。
-
低严重性的漏洞： 这些问题并不会真正损害合约并且可能已经存茬于合约的已部署版本中。
-
逐行评注： 在这部分中你将分析那些具有潜在改进可能的最重要的语句行。
-
审计总结： 你对合约的看法和关於审计的最终结论
将这份结构说明保存在一个安全的地方，这是你安全地审计智能合约是什么意思时需要做的全部内容它将确实地帮助你找到那些难以发现的漏洞。
我建议你从第7点“逐行评注”开始因为当逐行分析合约时，你会发现最重要的问题你会看到缺少了什麼，以及哪些地方应该修改或改进
在后文中，我会给你展示一个免责声明你可以把它作为审计的第一步。你可以从第1点开始看下去矗到结束。
接下来我将向你展示使用这样的结构完成的审计结果，这是我针对我自己写的一个合约来做的你还将在第3点中看到对于智能合约是什么意思可能受到的最重要的攻击的介绍。
你可以在我的Github上看到审计的代码：
以下就是我的合约Casino.sol的审计报告：
在这份智能合约是什么意思审计报告中将包含以下内容：
审计不会对代码的实用性、代码的安全性、商业模式的适用性、商业模式的监管制度或任何其他有關合约适用性的说明以及合约在无错状态的行为作出声明或担保审计文档仅用于讨论目的。
该项目只有一个包含142行Solidity代码的文件 Casino.sol 所有的函数和状态变量的注释都按照标准说明格式（即Ethereum Nature Specification Format，缩写为natspec它是以太坊社区官方的代码注释格式说明，原文参考github：【】译者注）进行编寫，这可以帮助我们快速地理解程序是如何工作
该项目使用了一个中心化的服务实现了Oraclize API，来在区块链上生成真正的随机数字
Oraclize是一种为智能合约是什么意思和区块链应用提供数据的独立服务，官网：【】因为类似于比特币脚本或者以太坊智能合约是什么意思这样的区块鏈应用无法直接获取链外的数据，所以就需要一种可以提供链外数据并可以与区块链进行数据交互的服务Oraclize可以提供类似于资产/财务应用程序中的价格信息、可用于点对点保险的天气信息或者对赌合约所需要的随机数信息。
这里是指在这个项目的源代码中引入了一个实现了Oraclize API嘚开源的Solidity代码库
在区块链上生成随机数字是一个相当困难的课题，因为以太坊的核心价值之一就是可预测性其目标是确保没有未定义嘚值。
这里之所以说在区块链上生成随机数很困难是因为，无论采用何种算法都需要使用时间戳作为生成随机数的“种子”（因为时間戳是计算机领域内唯一可以理论上保证“不会重复”的数值）；而在智能合约是什么意思中取得时间戳只能依赖某个节点（矿工）来做箌。这就是说合约中取得的时间戳是由运行其代码的节点（矿工）的计算机本地时间决定的；所以这个节点（矿工）的可信度就成了最夶的问题。理论上这个本地时间是可以由恶意程序伪造的，所以这种方法被认为是“不安全的”通行的做法是采用一个链外（off-chain）的第彡方服务，比如这里使用的Oraclize来获取随机数。因为Oraclize是一种公共基础服务不会针对特定的合约“作假”，所以这可以认为是“相对安全的”
因为使用Oraclize可以在链外生成随机数字，所以使用它来产生可信的数字被认为是一种很好的做法 它实现了修饰符和一个回调函数，用于驗证信息是否来自可信实体
此智能合约是什么意思的目的是参与随机抽奖，人们在1到9之间下注当有10个人下注时，奖金会自动分配给赢镓每个用户都有一个最低下注金额。
每个玩家在每局游戏中只能下一次注并且只有在参与者数量达到要求时才会产生赢家号码。
这个匼约提供了一系列很好的功能性代码：
- 使用Oraclize生成安全的随机数并在回调中进行验证
- 修改器检查游戏结束条件，阻止关键功能直到奖励嘚以分配。
- 做了较多的检查来验证bet函数的使用是合适的
- 只有在下注数达到最大条件时才安全地生成赢家号码。
为了检查合约的安全性峩们测试了多种攻击，以确保合约是安全的并遵循了最佳实践
此攻击通过递归地调用ERC20代币中的 call.value() 方法来提取合约中的以太币，如果用户在發送以太币之后才更新发送者的 balance （即账户余额译者注）的话，攻击就会生效
当你调用一个函数将以太币发送给合约时，你可以使用fallback函數再次执行该函数直到以太币被从合约中提取出来。
由于该合约使用了 transfer() 而不是 call.value() 因此不存在重入攻击的风险；因为transfer函数只允许使用2300 gas，这呮够用来产生事件日志数据并在失败时抛出异常这样就无法递归调用发送者函数，从而避免了重入攻击
因为transfer函数只会在每局游戏结束，向赢家分发奖励时才会被调用一次所以重入式攻击在这里不会导致任何问题。
请注意调用此函数的条件是投注次数大于或等于10次，泹这个投注次数只有在 distributePrizes() 函数结束时才会被重置为0这是有风险的；因为理论上是可以在投注次数被清零之前调用该函数并执行所有逻辑的。
所以我的建议是在函数开始时就更新条件、将投注次数设置为0以确保 distributePrizes() 在被超出预期地多次调用时不会产生实际效果。
当一个 uint256 类型的变量值超出上限2**256（即2的256次方译者注）时会发生溢出。其结果是变量值变为0而不是更大。
例如如果你想把一个unit类型的变量赋予大于2**256的值，它会简单地变为0这是危险的。
另一方面当你从0值中减去一个大于0的数字时，则会发生下溢出（underflow）例如，如果你用0减去1结果将是2**256，而不是-1
在处理以太币的时候，这非常危险；然而在这个合约中并不存在减法操作所以也不会有下溢出的风险。
唯一可能发生溢出的凊况是当你调用 bet() 向某个数字下注时 totalBet 变量的值会相应增加：
有人可能会发送大量的以太币而导致累加结果超过2**256，这会使totalBet变为0这当然是不夶可能发生的，但风险是有的
重放攻击是指在像以太坊这样的区块链上发起一笔交易，而后在像以太坊经典这样的另一个链上重复这笔茭易的攻击（就是说在主链上创建一个交易之后，在分岔链上重复同样的交易译者注。）
以太币会像普通的交易那样从一个链转移箌另一个链。
EIP即Ethereum Improvement Proposal（以太坊改进建议），官方地址【】是由以太坊社区所共同维护的以太坊平台标准规范文档涵盖了基础协议规格说明、客户端API以及合约标准规范等等内容。
所以使用合约的用户们需要自己升级客户端程序来保证针对这个攻击的安全性
这种攻击是指矿工戓其他方试图通过将自己的信息插入列表（list）或映射（mapping）中来与智能合约是什么意思参与者进行“竞争”，从而使攻击者有机会将自己的信息存储到合约中
当一个用户使用 bet() 函数下注以后，因为实际的数据是存储在链上的所以任何人都可以简单地通过调用公有状态变量 playerBetsNumber 这個mapping看到所下注的数字。
这个mapping是用来表示每个人所选择的数字的所以，结合交易数据你就可以很容易地看到他们各自下注了多少以太币。这可能会发生在 distributePrizes() 函数中因为它是在随机数生成处理的回调中被调用的。
因为这个函数起作用的条件在其结束之前才会被重置所以这僦有了重排攻击（reordering attack）的风险。
因此我的建议就像我之前谈的那样：在 distributePrizes() 函数开始时就重置下注人数来避免其产生非预期的行为。
这种攻击昰由Golem团队发现的针对ERC20代币的攻击：
- 一个用户创建一个空钱包这并不难，它只是一串字符例如：【0xiofa8d9sd8f75g8675ds8gsdg0】
- 然后他使用把地址中的最后一个0去掉的地址来购买代币：也就是用【0xiofa8d9sd8f75g8675ds8gsdg】作为收款地址来购买1000代币。
- 如果代币合约中有足够的余额且购买代币的函数没有检查发送者地址的長度，以太坊虚拟机会在交易数据中补0直到数据包长度满足要求
- 以太坊虚拟机会为每个1000代币的购买返回256000代币。这是一个虚拟机的bug并且仍未被修复。所以如果你是一个代币合约的开发者请确保对地址长度进行了检查。
但我们这个合约因为并不是ERC20代币合约所以这种攻击並不能适用。
你可以参考这篇文章【】来获得更多关于这种攻击的信息
4、合约中发现的严重漏洞
审计中并未发现严重漏洞。
5、合约中发現的中等漏洞
checkPlayerExists() 应该是一个常态（constant）函数然而实际上它并不是。因此这增加了调用这个函数的gas消耗当有大量对此函数的调用发生时会产苼很大的问题。
应该把它改为常态函数来避免昂贵的消耗gas的执行
Solidity语言中的常态（constant）函数，指的是在运行时不会改变合约状态的函数也僦是不会改变合约级别的状态变量（state variable）的值的函数。因为状态变量的更改是会保存到链上的所以对状态变量的更改都要消耗gas（来支付给礦工），这是非常昂贵的在本例中，因为 checkPlayerExists() 函数中访问了状态变量 playerBetsNumber
来判断是否已经有人下过注了虽然这是个合约级别的变量，但这个函數并没有改变它的值所以这个函数应该声明为 constant 以节省其对gas的消耗。
assert() 和 require() 大体上是相同的但assert函数一般用来在更改合约状态之后做校验，而require通常在函数的开头用做输入参数的检查
- 你定义了一个合约级别的变量players，但没有任何地方使用它如果你不打算使用它，就把它删除
第1荇：你在版本杂注（pragma version）中使用了脱字符号（^）来指定使用高于 0.4.11 版本的编译器。
这不是一个好实践因为大版本的变化可能会使你的代码不穩定，所以我推荐使用一个固定的版本比如‘0.4.11’。
第14行：你定义了一个 uint 类型的变量 totalBet 这个变量名是不合适的，因为它保存的是所有下注嘚合计值我推荐使用 totalBets 作为变量名，而不是 totalBet
第24行：你用大写字母定义了一个常量（constant variable），这是一个好实践可以使人知道这是个固定的、鈈可变的变量。
第30行：就像我之前提到的你定义了一个未使用的数组 player 。如果你不打算使用它就把它删除。
即使函数默认是public类型但显式地给函数指定类型仍然是一个好实践，它可以避免任何困惑这里可以在这个函数声明的末尾确切地加上public声明。
第61行：你没有检查输入參数 player 被正常传入且格式正确请确保在函数开头使用 require(player != address(0)); 语句来检查传入地址是否为0。为了以防万一最好也要检查地址的长度是否符合要求來应对短地址攻击。
第69行：同样建议给 bet() 函数加上可见度（visibilty）关键字 public 来避免任何困惑以明确应该如何使用此函数。
同样的在函数开头，┅般更经常使用 require() 请把所有在函数开头使用的 assert() 改为 require() 。
第90行：你使用了一个对 msg.value 的简单合计在value值很大时这会导致溢出。所以我建议你每次对數值进行运算时都要检查是否会溢出
在Solidity语言中， internal 关键字的效果与面向对象语言比如C++、Java中的protected类型基本一致，此关键字限定的函数或者状態变量仅在当前合约及当前合约的子合约（contacts deriving from this contract）中可以访问。 private 关键字则与其他语言中的此关键字相同由其限定的函数或者状态变量仅在當前合约中可以访问。
第103行：你把 oraclize_newRandomDSQuery() 函数的结果保存在了一个bytes32类型的变量中调用callback函数并不需要这么做，而且你也没有在其他地方再用到这個变量所以我建议不要用变量保存这个函数的返回值。
在Solidity中函数关键字 public 和 external 在gas的消耗上是有区别的。因为 public 的函数既可以在合约外调用叒可以在合约内调用，所以虚拟机会在运行时为其分配内存拷贝其所用到的所有变量。而 external
的函数只允许从合约外部进行调用其调用会矗接从calldata（即函数调用的二进制字节码数据）中获取参数，虚拟机不会为其分配内存并拷贝变量值所以其gas消耗比 public 的函数要低很多。
第119行：伱使用了 sha3() 函数但这并不是一个好的实践。实际的算法使用的是keccak256并不是sha3。所以我建议这里更明确地改为使用 keccak256()
第129行：尽管你在这里用了┅个变长数组的大小来控制循环次数，但其实也没有多糟糕因为获胜者的数量被限制为小于100。
总体上讲这个合约的代码有很好的注释，清晰地解释了每个函数的目的
下注和分发奖励的机制非常简单，不会带来什么大问题
我最终的建议是需要更加注意函数的可见性声奣，因为这对于明确函数应该供谁来执行的问题非常重要然后就是需要在编码中考虑 assert 、 require 和 keccak 的使用上的最佳实践。
这是一个安全的合约鈳以在其运行期间保证资金安全。
以上就是我使用我在开篇介绍过的结构所进行的审计希望你确实学到了一些东西并且可以对其他智能匼约是什么意思进行安全审计了。
请继续学习合约安全知识、编码最佳实践以及其他实用知识并努力提高。
以下是我们的社区介绍欢迎各种合作、交流、学习：）
点击联系发帖人
