分类 开发文档 下的文章 - 六币之门

017：Solidity语法之数组|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第六课分为三部分：Solidity语法之数组 Solidity语法之合约 Truffle简介与使用 这篇文章是第六课第一部分的学习笔记：Solidity语法之数组。上一小节简要介绍了 Solidity 的基础语法。还有两部分重要的内容要重点讲解一下，分别是数组和合约。这节课主要讲解 Solidity 数组相关知识，并有若干实例辅助理解。1、动态数组，bytes，string数组知识点在Solidity语法中，数组中主要有两种。一种是动态数组，主要是storage类型；另一种是定长数组，一般是memory类型。在这两个类型之外，还有两种特殊的类型，一是字节数组（bytes），一个是字符串（string），通常字符串可以转换成字节数组。1.1 动态数组length 在声明后可以改变，从而调整数组大小（静态数组不可以）。 push 向数组尾部附加一个元素，返回新的 length 。 bytes 数组指的是原始的字节串。其它类型（例如byte）的动态数组一个元素会占32字节，但是bytes每一个元素就是一个字节（更为紧凑，节省GAS）。可以把String 转换为 bytes 。对于定长的bytes，index 操作是只读！这里要特别注意。而对动态数组，index操作是可读写！ delete 只是 reset 该元素（重置为0），并不是通常意义的删除。【例子②】 1.2 字符串UTF-8 编码的结果。没有length 的概念。 UTF-8 是变长的编码方式，1-4个字节表示一个符号。对于英文和ASCII码是相同的。中文常见是3个字节。 所以String的长度一般是通过转化为 bytes 数组后，只能得到 bytes 数组的长度。 缺乏缺省的各类 string 操作，需要库支持（比如strcmp，strlen）。 bytes 无法直接转换到string，需要库支持。后面这两条是不完善的地方，不方便编程。 后面通过例子来理解这些知识点。2、实例讲解2.0 概览对于动态数组，讲解四个知识点：uint 动态数组【例子①】 bytes 定长数组【例子①】 string转换bytes【例子③】 手动的删除【例子②⑤】 对于字符串，讲解两个知识点：字符串的长度。根据 UTF-8 编码的规定来计算字符长度。【例子③】 字符串的比较。Keccak256 取巧的办法。【例子④】 演示代码在老师的代码托管网站上，获取方法见第二课第3小节。2.1 例子①拉取代码后，用 Remix 打开 example_1.sol 文件。在 settings 设置 Solidity version 为0.4.17，不要太高。本课的例子操作：点 Deploy 部署。 点 TestArray 执行。再看控制台，可以看到 TestArray 函数的返回值：bts1的长度变成了5。 点控制台上的debug，调试。 点击行号可以设置断点，此处演示把57行和69行设置为断点。右边可以在 solidity state 和 solidity locals 看到各变量的值。 点击调试按钮，最后一个：跳到下一个断点。执行结果1 点击调试按钮（第一行最后一个按钮），使走完一个循环。执行结果2 可以看到：ex_1的第0个元素发生了变化，bts2 变成了0x09020304。再点击几次“跳到下一个断点”按钮。使跳出循环。执行结果3 可以看到：bts1 变成了0x0506070809，bts2 变成了0x09020304。点击memory，可以看到变量在内存中的存储情况。 变量的存储ex_1，见代码第48行，byte 就是bytes1 ，ex_1是字节数组（见47行注释）。它的每一个元素都是32字节。如图上半部分四个小框。而bts1，是原始字节串，整个元素占一个字节。它不能按偏移量修改，能整体修改。如图下半部分。点击停止按钮。结束调试。 2.2 例子② 删除操作：修改代码。取消注释82行，注释掉84行，先演示默认删除的效果。 重新部署代码。Deploy 点击TestDelete，观察到返回值为4，意思是并没有删除，只是清零了。默认删除效果 取消注释84行，注释掉82行。再观察手动删除效果。这里使用了137行的自定义函数。实现方法是：把待删除位置之后的元素都向前移动一位，把最后一个元素置0，再把长度减少1。调试结果如图。手动删除效果返回值为长度3，88被删除了。 2.3 例子③ 字符串长度如果返回值是第38行，返回6；如果返回返回值是40行，则是2。后者符合期望值。实现方法在代码的第114行。（对UTF-8不懂，先放下不看）2.4 例子④ 字符串比较通过计算 Keccak256 ，如果这个值相等，则字符串是相等的。（演示略）2.5 例子⑤ 映射的删除默认的删除操作也是只清零，并没有真的删除（演示略）。编程时要注意。小结一下，本节通过例子介绍了solidity数组和字符串的使用。不足之处，请批评指正。

018：Solidity语法之合约|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第六课分为三部分：Solidity语法之数组 Solidity语法之合约 Truffle简介与使用 这篇文章是第六课第二部分的学习笔记：Solidity语法之合约。第5课第3小节简要介绍了 Solidity 的基础语法。还有两部分重要的内容要重点讲解一下，分别是数组和合约。这节课主要讲解Solidity合约相关知识，并有若干实例辅助理解。1、合约相关知识点合约相关知识点1.1 合约调用合约间接口相互调用□ address.function(para)□ address.call(func_signature, para) 合约之间转账□ address.transfer()□ address.send()□ address.call()□ - address.call.gas(num).value(num)() 缺省的是使用所有可用的Gas 调用深度是1024。一般正常情况不会这么多，除非发生递归。 delegatecode()，主要是调用库函数，但还是在当前函数的上下文环境。（第四课出现过） 1.1 转账需要注意的问题可以收钱的接口需要payable。 转账会触发接收账户的fallback函数(payable)。fallback函数，一个匿名函数。 transfer 仅仅转发2300 gas， 失败会抛出异常。fallback 要非常简单。 send 仅仅转发2300 gas， 失败只会返回false。fallback 要非常简单。 call.value(amount)() 会转发全部的可用的gas，失败只会返回false，容易引起重入型攻击。 2、合约相关实例1、合约间接口调用实例代码见git仓库，或见下图。合约间接口调用实例打开文件 example_2.sol ，编译。 在 run 页面，选择 B_caller ，点击 Deploy 。下面出现三个接口。B合约的三个接口 在调用合约前，先显示一下A的状态值，点 Getstate_A，显示为0。 显式调用，点击Invocate_A，再点击 Getstate_A，结果为15，正确。 call调用。点击 Call_A ，返回值为真。再点击 Getstate_A，结果为23，正确。 特别注意：代码第45行。keccak256在计算签名时，函数的参数要写全称uint256，不要写简称uint，否则会出现问题。因为签名算法是根据字符串算的，它不会自动把简称替换成全称。1、合约间接口调用实例合约转账实例关闭example_2.sol，打开example_3.sol，（有时需要刷新一下浏览器） 编译，或勾上自动编译。 在 run 页面，选择 B_caller ，点击 Deploy 。下面出现四个接口。B合约的三个接口 在调用合约前，先显示一下A的状态值，点 Getbalance_A，显示为0。 Value值输入6666，点击 Transfer_A，再点击 Getbalance_A，结果为6666，正确。 Value值输入8888，点击 Sender_A ，返回值为真。再点击 Getbalance_A，结果为15554，正确。 Value值输入1，点击Call_A，返回值为真。再点击 Getbalance_A，结果为15555，正确。 以上是将9～11行注释掉的情况。现在去掉这三行的注释，再操作一遍。Transfer_A、Sender_A 操作均失败， Call_A 成功。而把49行代码换成第48行代码时，又会转账失败。其中，9～11的三行代码会消耗6万个Gas 。transfer、send 仅仅转发2300个Gas，所以会失败。而Call调用方法，缺省是支付所有Gas，在本例中若限制5万个Gas，则转账失败。小结一下，本小节主要讲解了 Solidity 合约相关知识，并有两个实例辅助理解。不足之处，请批评指正。

019：Truffle简介与使用|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第六课分为三部分：Solidity语法之数组 Solidity语法之合约 Truffle简介与使用 这篇文章是第六课第三部分的学习笔记：Truffle简介与使用。这节课主要讲解了 Truffle 的技术特性，并演示了 Truffle 的安装和一个小例子。1、Truffle 简介前面介绍的 Remix 作为学习工具来用是比较好的，但是不能满足生产环境。因为 Remix 不支持 web 前端、自动化程度不是很高，不方便进行自动化测试。实际工作中用到的是Truffle框架。1.1 技术特性Consensys 出品，智能合约开发测试框架 内置的编译 / 链接 / 部署 快速开发自动合约测试 可以部署到 TESTRPC/ 测试网络 / 主网（TESTRPC现在更名为ganache） 直接可与合约通信的交互 Console 调试合约 集成了 web / javascript 组件，可以直接运行 App web 前端 1.2 安装要求ubuntu 16.04 Nodejs LTS 8.11 ganache-cli 为测试网络（速度快，不需要挖矿。） 2、Truffle 开发演示马老师把演示的步骤放在了代码仓库：lesson_6/truffle_setup.txt 。下面是我的操作记录。2.1 Truffle 安装安装NVM。Truffle 是基于 Node.js 开发的，使用时需要node的版本在 8.0 以上，管理版本用的工具是Nvm。安装命令如下： curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.9/install.sh | bash 确认各个软件都已安装齐。我这步出了点问题，重启了一下终端，好了。 sudo apt install build-essential python -y 退出终端exit，使安装的 nvm 生效。也可以不退出，使用如下命令，生成一个子进程。 exec bash 安装 node.js 的长期稳定版。我安装之后是8.11.2版。 nvm install --lts 再把 npm 更新一下。更新后版本是6.0 npm install -g npm 安装 Truffle 和 ganache，另外还要安装webpack并指定版本4.0 。我这步安装了20多分钟，电脑发热的厉害。最后安装成功，Truffle 的版本是4.1.9 npm install -g truffle ganache-cli webpack@4.0.0 2.2 Truffle 实例在工作目录新建一个文件夹。我的工作目录是ETHljx，新建文件夹是hello_world 。再进入到文件夹。 cd ~/ETHljx mkdir hello_world cd hello_world 用Truffle 生成一个自带的例子。这是一个很简单的例子，并不是ERC20的代币，仅作练习使用。 truffle unbox webpack 编译 truffle compile 编译后可以看到有三个 .sol 文件。主要是 MetaCoin.sol 文件。查看文件 vim contracts/MetaCoin.sol MetaCoin.sol代码查看完代码后，在命令模式下按 :q! 退出vim 。使用 tmux 再开一个窗口，启动ganache测试网络（右边窗口）。 ganache-cli -h 0.0.0.0 上面的命令是老师的，用的是两台机器，一个远程服务器。我的是在同一台电脑上练习，用下面的命令，即不加后面的参数：ganache-cli 启动后，可以看到10个账号，和对应的私钥。复制下来一个账号。端口号8545要记下来。部署合约（左边窗口） truffle migrate 修改 truffle.js 改端口号到 8545, ip 到本机对应的外部IP(非 127.0.0.1)。注意：前面这句是马老师的情况（使用两台机器），我用的一台机器，所以，IP还得写127.0.0.1 。（老师的是192.168.1.12） 修改 package.json，第8行的端口号8008 。 修改 app/javascript/app.js 修改ip地址和端口号 否则不能正常运行 vim app/javascript/app.js window.web3 = new Web3(new Web3.providers.HttpProvider("http://192.168.1.12:8545"));//这是老师的，IP和第13步一样；端口号改成8545。 window.web3 = new Web3(new Web3.providers.HttpProvider("http://127.0.0.1:8545"));//这是我的。 启动 npm run dev 在浏览器地址栏输入127.0.0.1:8008，打开web前端。可以看到当前有10000个Meta币。给刚才复制的账号转88个币，输入88，粘贴地址，点击Send MetaCoin。之后，余额少了88个币。再回到测试网络，可以看到，区块号增加了1。 演示结束。 Ctrl + Z：停止左边的 web 服务，Ctrl + B，→：切换到右边窗口，Ctrl + C：停止测试网络。exit：关闭一个tmux窗口，退出 tmux，退出默认的终端，都是这个命令。小结一下，本节简要介绍了Truffle的技术特性，演示了Truffle的安装过程，并运行了一个简单的实例。不足之处，请批评指正。

020：Solidity语法之多继承|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第七课分为三部分：Solidity语法之多继承 ERC20众筹实例之合约分析 ERC20众筹实例之部署调试 这篇文章是第七课第一部分的学习笔记：Solidity语法之多继承。在前面的课程中，分别讲解了 Solidity 语言的两个语法难点：数组和合约，这节课继续讲解另一个语法难点：多继承，并有两个代码示例辅助理解知识点。1、多继承规则1.1 多继承规则多继承规则多继承经常出现在面向对象的编程语言中。但往往有二义性，影响代码的可读性、可维护性。在多继承中，有个经典的钻石问题。如图所示，B、C都是继承自A，D同时继承自B和C，D的test方法就会遇到问题。Solidity 智能合约为了解决这个问题，使用了C3线性化（维基链接）。D继承B和C时，根据书写的顺序，有继承的先后，如图中虚线所示，按DCBA的顺序。1.2 实例example_4.solexample_4.sol代码中，super是指父类的意思。Run 页面，先选择 D 合约，Deploy 部署代码； 再点 test 接口，下方点 Debug ； 在第 31、48、66 行设置断点； 点击跳到下一个断点，执行到第 66 行； 点 step into 进入到内部，执行到 C 合约内部； 点击跳到下一个断点，执行到第 48 行； 点 step into 进入到内部，执行到 B 合约内部。注意，这里不是跳到A合约，而是B合约。 后续演示略。从B合约可以再进入A合约。 2、复杂类型复杂类型接下来是两个非常隐蔽的语法难点。2.1 局部变量类型一个函数里，局部变量的常规类型是 memory，而局部变量类型如果是复杂类型，则其缺省类型是这个复杂类型的指针。就是说，如果不显式地声明它是 memory 类型的话，它就是指向复杂类型的 storage 指针。注意这里，指针是指向 storage 的，而不是 memory 。第二句如图。所以，在使用时，为了避免二义性，要显式地声明变量的类型。2.2 var 类型推导第二个易错的错误是var类型推导。如图举例，如果把 x 推导为 8 位无符号整型，范围是0～255，在循环函数中，永远执行不完所有的循环，这会引起死循环，直到消耗完 gas 。所以，要避免这类错误。2.3 实例example_5.solexample_5.sol把编译器版本设置为0.4.17，高版本的有点儿问题。 部署 点击 test_Local_Var 接口，再点击下面的Debug，在调试区可以看到state_A的长度为4，如图。点击test_Local_Var 在第 31 行设置一个断点，执行到断点处。此时state_A的长度变为9999，如图。执行x.a=9999后因为长度length就是存在起始的位置上，x.a=9999改变了这个值。因为指针缺省指向整个合约实例的存储类型状态变量的起始地址（见课件文字）。这里要特别注意！数组的长度本来应该是4，现在成了9999，这会浪费很多 gas 。 本例的第二个接口是 var 类型推导，前文已说明，如果用第 39 行代码，会是死循环；而用第 38 行代码，则是可以的。 小结一下，本文主要讲解了 solidity 语法难点中的多继承，并有两个代码示例辅助理解。不足之处，请批评指正。

021：ERC20众筹实例之合约分析|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第七课分为三部分：Solidity语法之多继承 ERC20众筹实例之合约分析 ERC20众筹实例之部署调试 这篇文章是第七课第二部分的学习笔记：ERC20众筹实例之合约分析。（1）这节课主要讲解了一个众筹合约的代码分析（Open Zeppelin 框架）。这里的众筹，有个高大上的名字叫 ICO 。ICO（是Initial Coin Offering缩写），首次币发行，源自股票市场的首次公开发行（IPO）概念，是区块链项目首次发行代币，募集比特币、以太坊等通用数字货币的行为。1、Open Zeppelin Token 分析这个众筹合约是基于 Open Zeppelin 安全智能合约开发框架来实现的。这个框架下有很多不同的合约，这里主要介绍跟 ERC20 有关的。关于 ERC20 在第五课中有过分析。 ERC20 规范有六个接口组成，在Open Zeppelin 中分解到了 4 个合约来完成。如图。Open Zeppelin 合约首先是 ERC20 Basic，这是一个抽象合约，就是它只定义了接口，没实现功能。它是一个最基础的合约，在这个合约中，它定义了三个接口，totalSupply, banlanceOf, transfer。然后是延伸出 ERC20 合约。它扩展定义了三个新的接口，allowance, transferFrom, approve，依然是没有实现，这是个抽象合约。再一个是 Basic Token 合约，它继承自 ERC20 Basic，实现了 ERC20 Basic 的三个接口。这里面有一个映射，mapping(address=> uint256)，是地址到余额的映射。Standard Token 继承自 ERC20 ，基本实现了扩展合约中的三个接口。因为它也继承自 Basic Token ，所以它还有 Basic Token 所实现的三个功能。这是一个典型的钻石型多继承关系。这里面的映射相对来说复杂一些，mapping (address => mapping(address => uint256))，允许其它的账户从一个账户取走多少额度。后面是一个 Mintable Token，类似于一个造币厂的功能，根据有多少人来买，来增加供给量。它还继承自 Ownable 合约，它不但允许在初始时设置合约所有者的所有权，也允许更换所有者。框架中还用到了 SafeMath Lib，主要是处理一些数学问题，比如防止溢出。2、Open Zeppelin 代码在执行了本课第三部分的安装等工作后，可以查看到有关 Open Zeppelin 的代码。接下来分析一下具体的代码。2.1 ERC20Basic.sol/node_modules/openzeppelin-solidity/contracts/token/ERC20/ERC20Basic.sol进入到 /node_modules/openzeppelin-solidity/contracts 目录，执行 vim token/ERC20/ERC20Basic.sol 打开这个文件。ERC20Basic.sol它是一个抽象合约，并没有实现具体的接口，只是定义了这三个接口。如图。第一个是查询总的供给量。第二个是查询特定帐户的余额。第三个是转账。最后还定义了一个事件，记录转账这个事件。2.2 ERC20.sol/node_modules/openzeppelin-solidity/contracts/token/ERC20/ERC20.solERC20.sol这个 ERC20.sol 仍然是一个抽象合约，它继承自 ERC20Basic.sol ，所以在第 3 行引入了 ERC20Basic.sol 的源代码。它定义了三个接口和一个事件。第一个是 allowance ，意思是 spender 可以从 owner 那里取多少余额。第二个是一个地址到另一个地址的转账操作。第三个是甲方向一个特定的乙方授予一定的额度。最后是记录这个事件，已被应用程度来查询。2.3 StandardToken.sol/node_modules/openzeppelin-solidity/contracts/token/ERC20/StandardToken.solStandardToken.sol这个 StandardToken.sol 继承自 ERC20.sol 和 BasicToken.sol，所以在第 3、4 行引入了 这两个合约。第25、47、59行，分别实现了以下三个接口。function transferFromfunction approvefunction allowance接下来是两个自定义的接口，不再是 ERC20 中强制规定的接口。一个是增加余额的额度（第73行），它的实现方式不是直接赋予一个新值，这种方式有漏洞，不安全，在前面的注释中有说明。它是使用原有的值，使用SafeMath增加一个数值，再来更新。避免两次操作（这里不懂）。同时记录下事件。另一个是相反的操作，减少额度（第89行）。这里有一个例外，就是降低的数值超过了原有的额度，就置为 0 。不例外的情况下，它也是使用 SafeMath 函数，做一个减法，同时记录下事件。2.4 Ownable.sol/node_modules/openzeppelin-solidity/contracts/ownership/Ownable.solOwnable.sol这个主要是管理合约的发起人。这种模式很常用，在构造函数中记录合约的发起人，之后一般是增加一个修饰器，专门检查调用这个合约的人是不是合约的发起人。这个合约有个特殊的地方就是，它允许你转发合约所有者的身份。只有合约的所有者才能转让，它会转让一个新的地址，先检查地址是否为空，如果不空，记录这个事件，把所有者设置为新的所有者。2.5 MintableToken.sol/node_modules/openzeppelin-solidity/contracts/token/ERC20/MintableToken.solMintableToken.sol这个是造币的合约。它继承自 Ownable.sol 和 StandardToken.sol 合约（第13行），还有两个事件，一个是造币，一个是造币结束。后面是一个布尔值，如果为真，表示造币活动停止（发行结束）。第 31 行是向一个地址发行代币，这条只有合约的所有者才可以执行。同时还要检查发行活动是否继续。如果都没有问题，先增加总供给量，同时也要对目标地址的余额进行更新，记录下两个事件。下面 43 的接口也是只能合约的所有者才可以调用。检查是不是正在发行，如果发行活动结束了，就把“结束”设为真，记录下这个事件。小结，这节课主要讲解了Open Zeppelin 安全智能合约开发框架，并分析了其中的几个代码文件。代码涉及的知识点比较多，平时要注意多积累。不足之处，请批评指正，谢谢。课程地址为：深入浅出ETH原理与智能合约开发

022：ERC20众筹实例之合约分析2|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第七课分为三部分：Solidity语法之多继承 ERC20众筹实例之合约分析 ERC20众筹实例之部署调试 这篇文章是第七课第二部分的学习笔记：ERC20众筹实例之合约分析。（2）前一小节介绍了发币相关的合约，这一小节介绍众筹相关的合约。1、Zeppelin Crowdsale 分析Crowdsale 简介Crowdsale 是一个基类合约，它提供了很多的接口，提供给子合约来重载。它的一个核心功能 buytoken ，不能被重载，它是由 fallback 函数触发。下面的两个合约都继承自 Crowdsale 。一个是 TimedCrowdsale 合约（限制的众筹，有开始时间和结束时间，在两者之间有效），一个是 MintedCrowdsale 合约（按需发币的众筹）。基类合约 Crowdsale 引用的是一个 ERC20 抽象合约的地址，而在 MintedCrowdsale 中引用的则是 MintableToken 地址。自己的众筹合约继承自 TimedCrowdsale 合约和 MintedCrowdsale 合约。自定义的 Mytoken 是基于 MintableToken 合约。2、Open Zeppelin 代码2.1 Crowdsale.sol/node_modules/openzeppelin-solidity/contracts/crowdsale/Crowdsale.solCrowdsale.sol部分代码的分析见图中注释。2.2 MintedCrowdsale.sol/node_modules/openzeppelin-solidity/contracts/crowdsale/emission/MintedCrowdsale.solMintedCrowdsale.solMintableCrowdsale 子合约继承自基类合约 Crowdsale 合约。这个合约只有一个功能，就是重载了 deliverToken ，怎么给受益人发放 Token 。在基类中是直接调用的 transfer，这里是先把类型转换，转成 mintabletoken ，然后调用 mint，向受益人发币。2.3 TimedCrowdsale.sol/node_modules/openzeppelin-solidity/contracts/crowdsale/validation/TimedCrowdsale.solTimedCrowdsale.sol部分代码的分析见图中注释。小结。本节主要介绍众筹相关的三个合约源文件。不足之处，请批评指正，谢谢。课程地址为：深入浅出ETH原理与智能合约开发

023：ERC20众筹实例之部署调试|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第七课分为三部分：Solidity语法之多继承 ERC20众筹实例之合约分析 ERC20众筹实例之部署调试 这篇文章是第七课第三部分的学习笔记：ERC20众筹实例之部署调试。这节课主要讲解了一个众筹实例的部署调试。（ 部署工作还是在 Truffle 中进行，之前的一个简单例子可见《019：Truffle简介与使用》 ）新建目录 mkdir ari_coin 进入到刚才新建的目录，用 truffle 初始化项目 truffle init 安装智能合约框架Zeppelin npm install -E openzeppelin-solidity 可以通过 cd 、 ls等命令查看目录、文件。 其中，有关openzeppelin的合约在air_coin/node_modules/openzeppelin-solidity/contracts 目录下。具体代码见前两小节的分析。（《分析1》和《分析2》）把老师的合约代码拷贝到 air_coin/contracts 目录 注：老师的合约代码在仓库中，可见这节。查看代码：vim 文件名①、air_coin/contracts/AirCoin.solpragma solidity 0.4.23; import 'openzeppelin-solidity/contracts/token/ERC20/MintableToken.sol'; contract AirCoin is MintableToken { string public name = "Air COIN"; string public symbol = "AIR"; uint8 public decimals = 18; } 这个合约说明 AirCoin 继承自 MintableToken ，定义了名称、符号、最小单位。②、air_coin/contracts/AirCoinCrowdsale.solpragma solidity 0.4.23; import './AirCoin.sol'; import 'openzeppelin-solidity/contracts/crowdsale/emission/MintedCrowdsale.sol'; import 'openzeppelin-solidity/contracts/crowdsale/validation/TimedCrowdsale.sol'; contract AirCoinCrowdsale is TimedCrowdsale, MintedCrowdsale { function AirCoinCrowdsale ( uint256 _openingTime, uint256 _closingTime, uint256 _rate, address _wallet, MintableToken _token ) public Crowdsale(_rate, _wallet, _token) TimedCrowdsale(_openingTime, _closingTime) { } } AirCoinCrowdsale 众筹合约继承自TimedCrowdsale 和 MintedCrowdsale 合约，开头先导入他们。在构造函数部分设置了开启时间，关闭时间，汇率、钱包地址，token地址。然后用这些参数初始化父类合约。修改 air_coin/truffle.js 代码，加入network 一串代码 module.exports = { // See <http://truffleframework.com/docs/advanced/configuration> // for more about customizing your Truffle configuration! networks: { development: { host: "192.168.1.12", //老师的是这个地址，我的用的localhost port: 8545, network_id: "*" // Match any network id } } }; 查看migrations/2_deploy_contracts.js 代码 2_deploy_contracts.js这个文件设置了开始时间，结束时间，汇率为8，集资的钱包地址为地址1 。在右边窗口打开ganache测试网络 ganache-cli tmux，进入 tmuxctrl + B, shift + 5, 左右分屏更多tmux的操作见这节。左边窗口 编译 truffle compile （需要把三个.sol文件的版本改为0.4.24） 部署合约 truffle migrate 连到测试网络 truffle console 设置购买人 buyer = web3.eth.accounts[2] ，购买人设置地址2 。 取得众筹实例： AirCoinCrowdsale.deployed().then(inst => ) 取得 token的地址： crowdsale.token().then(addr => ) 恢复一个实例： airCoinInstance = AirCoin.at(tokenAddress) ownship 换一下，转给众筹合约。airCoinInstance.transferOwnership(crowdsale.address)返回状态 status:'0x01' 成功 检查空气币的总供给，应该是零，还没有人买。airCoinInstance.totalSupply().then(supply => supply.toString(10)) 购买者的空气币余额也是零，还没有买。airCoinInstance.balanceOf(buyer).then(balance => balance.toString(10)) 利用众筹合约，购买500wei，crowdsale.sendTransaction()；或者 5 个以太币，crowdsale.sendTransaction()（只是不易观察，数字太长）。 重复17、18 步，查看余额，都是 4000，因为汇率是 8，500*8=4000 。 课后作业：500wei 转给地址1 了，怎么把它显示出来？经过翻书查资料，找到了下面两条指令，wallet=web3.eth.accounts[1]web3.eth.getBalance(wallet).toString()返回的结果是100000000000000000500（即，100×10^18+500，地址默认有100 ether，1 ether = 10^18 wei ），结果正确。小结：本课把前面两小节的众筹实例在 Truffle 上实现了出来，进行了部署，并演示了众筹的模拟。不足之处，请批评指正。

024：以太坊Web应用架构|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第八课分为三部分：以太坊Web应用架构 AirCoin WebUI 设计概要 AirCoin WebUI 实际开发演示 这篇文章是第八课第一部分的学习笔记：以太坊Web应用架构。这节课主要讲解了前节课所述空气币（AirCoin）的Web应用架构。1、以太坊Web应用组件在以太坊去中心化应用的前端技术中，主要使用了两个组件，一个是 web3，一个是 TruffleContract，这两个都是基于 JavaScript 的。Web应用组件1.1 web3jsweb3js 是以太仿官方的JavaScript接口，Go-Ethereum 官方客户端支持。它不但可以使用在 Http 中，还可以使用在 RPC 中，也可以使用在 Go-Ethereum 的控制台中，应用非常广泛。它现在有两个版本，0.2x 和 1.0 版本，其中 1.0 版本还在开发中，后面的例子中使用的是 0.2 版本。一般来讲，作为 JS 的类库，可以支持同步和异步两种模式，这节课的例子中也会用到两种模式。web3js 大约有几十种接口，主要使用的有上图中的四种。更多内容可以参见这里：《 js-api 》1.2 Truffle-ContractTruffle-Contract 是 Consensys Tuffle 框架的一部分，支持 nodejs 调用和浏览器调用两种形式。这节课的例子中是通过后者来调用。它是基于 web3js Contract 部分接口的封装。原因是在 web3js Contract 中要使用对应合约的 ABI 来实例化，而 Truffle 本身是个框架，有编译功能，有部署功能，所能提供的信息要远比 ABI 丰富，对这些信息进行更高级的封装，则就是 Truffle-Contract 。Truffle-Contract 的目标是更容易的操作以太坊智能合约。通过 nodejs 和浏览器创建合约对象的方法如图。其中 JSON 文件包含 ABI、网络ID、地址等信息。JSON 文件要满足 truffle-contract-schema 格式。生成合约对象后，通常还要再生成对应的实例，大概有三四种方法，最常用的方法是 deployed() 。生成合约实例之后，可以使用这个实例向对应的合约发起相关的调用，在后面的例子中会有演示。JSON 文件从哪来？它其实是 Truffle 编译时生成的文件，部署时，也会更新它。所以，这个 JSON 文件不止包含静态信息，也包含动态，如部署信息。因为部署信息只有在部署时才会有，所以 Truffle 对 JSON 文件进行了两次操作，一次是创建时，一次是更新时。更详细的信息见：《 truffle-contract 》2、以太坊Web应用架构以太坊Web应用架构以太坊Web应用架构主要有两种，图示左边的一种相对较简单，适用于服务器端逻辑简单的情况。随后的例子用的是这种。图示右边的一种是服务器端逻辑复杂的情况。第一种。web 前端通过调用 Trufflecontract，通过调用 web3js，来和FullNode 进行交互，这个全节点可以是 Geth，也可以是测试工具 Ganashi 。后面的例子中使用的是 Ganashi 。如果是 Geth 的话，还需要与主网联通。这种架构没有服务器端，逻辑全部依靠智能合约。如果逻辑复杂，代价就昂贵，响应速度还受制于主网的吞吐量。第二种。如果服务器端的逻辑较复杂，而大部分的内容不需要放到区块链上，就需要第二种架构。这种架构和传统的 C/S 架构还不相同，Client 和 Server 还不是直接通信。以电商购物说明一下。卖家向主网注册一个事件“买家向我打钱了”，当买家打钱时就会触发这个事件。同样，买家也向主网注册一个事件“卖家向我发货了”，当卖家发货时就会触发这个事件。之后，买家向区块链发起一笔交易向卖家付款，同时获得收据，同时这个收据也会到卖家，因为触发了事件“买家向我打钱了”。卖家此时就会发货，收据返回到卖家和买家，因为买家的事件“卖家向我发货了”被触发。客户端更新界面。这种架构中，只有很小的部分放到了区块链上，主要是涉及交易的部分。这里只是举例说明。这种架构的好处是可以节省费用。小结：这小节主要介绍了以太坊Web应用组件和两种应用架构。不足之处，请批评指正。

025：AirCoin WebUI 设计概要|《ETH原理与智能合约开发》笔记 待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。第八课分为三部分：Web应用架构 AirCoin WebUI 设计概要 AirCoin WebUI 实际开发演示 这篇文章是第八课第二部分的学习笔记：AirCoin WebUI 设计概要。这节课主要讲解了AirCoin Web 前端的设计概要。介绍了其中涉及到文件的作用，序列图，重点讲解了实现前端逻辑的 app.js 文件（下一篇）。1、AirCoin WebUI 设计概要空气币（AirCoin）来自于上节课的例子，它是一个基于 ERC 20 发行的代币，在那节课中只有后端的智能合约实现的逻辑，没有前端。这节课就实现它的前端逻辑。这个例子是一个官方的教学实例，马老师进行了大量的修改。WebUI 设计概要1.1 文件列表静态页面 index.html这个文件修改自 TutorialToken app.js这个文件实现了前端的逻辑，比如：读取合约的JSON文件、生成合约对象，合约实例；调用web3js、truffle-contract；批量转账等功能。 批量转账是向多个账户转账。它可以有两种方式，一种是在智能合约里实现，一种是在JS文件里实现，这节课中用的是后一种。2_deploy_contracts.js这个是合约的部署文件。 bs-config broswer-sync 配置文件前端的测试环境用了一个叫 broswer-sync 的东西，它可以动态地修改前端的参数，加快开发进度。 web3.min.js, truffle-contract.min.js这两个文件也需要更新一下。 1.2 序列图前端交互的时序图。实例中使用的 Ganashi 即代表是后端，也代表整个区块链，它是一个很方便的测试框架。前端就是上图中的webUI，它基于 TruffleContract 和 web3js 两个组件，和Ganashi 进行通信。时序图如上图，创建实例后，前端向两个智能合约发起调用，以及获得反馈。1.3 前端页面展示前端页面（我的电脑因升级导致虚拟机不能用了，这图是视频上截的）最上面是众筹的信息。总的供给量，对应账户及余额。下面是输入部分，账户，以太币，以wei为单位，汇率是8，两个按钮是买空气币，和批量转账。下面是每个账户对应的余额。展示以太币的变化情况。地址0是缺省地址，地址1是钱包地址，负责收钱。无论是谁花了以太币买空气币，都转到地址1；地址5到8演示批量转账。2、代码分析2.1 代码的目录前端的实现文件主要是在 src 文件夹。如图。另外，图中的 bs-config.json 是broswer-sync 的配置文件。目录截图（这图也是视频上截的）2.2 index.htmlindex.html局部截图上图是index.html的主要部分，加了 id 的，是需要使用 JS 更新的，后面结合 app.js 来分析。后面是一个table 表格，用来显示各个地址下的余额。再后面是加载相关的JS文件，其中 web3.min.js, truffle-contract.min.js 要用老师更新过的文件。2.3 app.js使用 vim src/js/app.js 打开文件。这个文件是本实例中最重要的JS文件，它实现了前端页面的所有逻辑。这些逻辑都包含在叫 App 的对象中。（没状态了，先放一放，下篇吧 -_-!!!）小结，这节主要介绍了AirCoin Web 前端的设计概要。不足之外，请批评指正。

以太坊（ETH）GAS详解 本文翻译自：http://ethdocs.org/en/latest/contracts-and-transactions/account-types-gas-and-transactions.html?highlight=gas#what-is-gas什么是Gas？以太坊在区块链上的的执行环境的实现称为以太坊虚拟机（EVM）。 参与网络的每个节点都运行EVM作为区块验证协议的一部分。 他们会检查正在验证的块中列出的交易，并运行由EVM中的事务触发的代码。 网络中的每个全节点执行相同的计算并存储相同的值。 显然，以太坊不是要优化计算效率。，因为它的并行处理是冗余的。在不需要可信的第三方，权威或暴力垄断的情况下，以太坊提供一种有效的方式来达成系统状态的共识。但是很明显，这不是最优的计算方式。合约执行是跨节点冗余复制的事实自然会使它们变得昂贵，这通常会产生不使用区块链进行离线计算的动机。当你运行一个去中心化应用（dapp）时，它会与区块链交互以读取和修改其状态，但是dapps通常只会放置对达成共识至关重要的业务逻辑和状态到区块链上。当由于消息或事务触发而执行合约时，每个指令都在网络的每个节点上执行。 这具有一定的成本：对于每个执行的操作都有指定的成本，以一定gas单位表示。Gas是交易发起人需要为以太坊区块链上的每项操作支付的执行费的名称。 gas这个名称的灵感来源于这种费用可以作为加密燃料，驱动智能合约的运动。 gas可以从执行代码的矿工那里购买。 由于gas单位与具有自然成本的计算单元对齐，因此gas和ether有意地解耦，而ether（以太）的价格通常是随市场波动的。 这两者是由自由市场调节的：gas的价格实际上是由矿工决定的，他们可以拒绝处理gas价格低于最低限额的交易。 你只需在你的账户中添加一定的以太币就可以获得gas。 以太坊客户端会自动为你的以太币购买gas，金额为您指定的金额，作为交易的最大支出。根据以太坊协议，在合约或交易中执行的每个计算步骤都要收取费用，以防止在以太坊网络上的恶意攻击和滥用。每笔交易都必须包含gas limit和愿意为gas支付的费用。矿工可以选择是否打包交易和收取费用。如果由交易产生的计算步骤所使用的gas总量(gas used )，包括原始消息和可能被触发的任何子消息，小于或等于gas limit，则处理该交易。如果gas总量超过gas limit，那么所有的改变都会回退，除非交易仍然有效并且矿工接受了这个费用。交易执行中未使用的所有多余的gas将以Ether返还给交易发起人。你不必担心超支，因为你只需支付消耗的gas费用。这意味着发送高于估计值gas limit的交易是有用的，也是安全的。估算交易成本交易中花费的总共的ether成本取决于2个因素：gasUsed:是交易中消耗的总共的gasgasPrice：在交易中指定一个单位gas的价格（ether）总费用 = gasUsed * gasPricegasUsedEVM中的每个操作都指定了要消耗的gas量。 gasUsed是执行所有操作的所有gas的总和。 有一个电子表格，提供了这背后的一些分析。为了估算gasUsed，这里有一个可以使用的estimateGas API，但有一些注意事项。gasPrice用户构造并签名交易时，每个用户都可以指定他们希望的任何gasPrice，它甚至可以是零。 然而，Frontier推出的以太坊客户端的默认gasPrice为0.05e12 wei。 由于矿工优化了他们的收入，如果大多数交易都是以0.05e12 wei的gas价格提交的，那么很难说服矿工接受指定较低或零的gas价格的交易。估算交易成本的例子举个例子，一个合约只是添加2个数字，EVM OPCODE ADD消耗3gas。使用默认gas价格（截至2016年1月）的大致成本为：3 * 0.05e12 = 1.5e11 wei注意：gas的最小单位为wei，1ether = 10^18wei换算成以太的话，就是0.00000015 Ether.question gas fees gas cost calculator Ethereum Gas Prices Operation Name Gas Cost Remark step 1 default amount per execution cycle stop 0 free suicide 0 free sha3 20 sload 20 get from permanent storage sstore 100 put into permanent storage balance 20 create 100 contract creation call 20 initiating a read-only call memory 1 every additional word when expanding memory txdata 5 every byte of data or code for a transaction transaction 500 base fee transaction contract creation 53000 changed in homestead from 21000