待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。
课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。
第五课分为三部分：
- Dapp用例
- 合约结构
- Solidity语法
这篇文章是第五课第二部分的学习笔记：合约结构 。
这节课主要讲解了智能合约结构、ERC20、ERC721规范。
1、智能合约结构
1.1 智能合约的结构
智能合约的源代码由以下7个部分组成。
-
版本声明
在以太坊的solidity编程语言中，各个大版本之间不具有兼容性，所以需要在开头声明版本号。不能在之前或之后的版本中运行，如pragma solidity ^0.4.x，不能在0.3或0.5的系统中运行。 -
包含其它代码文件：import
可以引入其它文件或者库。 -
合约的定义
使用关键字contract，后面跟上合约的名字。contract 合约名 -
存储状态变量
这部分内容需要存储在Storage Root中。（第3课） -
构造函数
它是一类很特殊的函数，它在合约被创建的交易中被执行一次，函数名需要与合约名相同。（与C++的构造函数类似） -
调用接口函数
提供给其它账户调用。 -
事件
用于记录关键这个步骤与信息。
1.2 智能合约的ABI
开发 DApp 时要调用在区块链上的 Ethereum 智能合约，就需要智能合约的 ABI。ABI（Application Binary Interface）主要是规范外部账户与合约之间二进制数据的编码规范。
要调用一个合约特定的接口，首先要有合约的地址。在这个合约众多的接口中，怎么找到需要调用的那一个，这就要用到函数签名。函数的签名由函数名与所有参数类型组成(返回值类型不算在内)，编码的前四个字节是函数签名的Keccak256 单向散列值的前四字节。如：function baz(uint32 x, bool y)这个函数，其编码的前四个字节是baz(uint32,bool)经过Keccak256计算后，再取前四个字节0xcdcd77c0。从第五字节开始对输入的实际调用参数进行编码，并补齐32字节。比如例子中的x, y分别取值0x88，0x1，补齐32字节。
1.3 通过 remix 介绍合约结构
1.3.1 一个小例子
打开remix网站，自带一个例子程序。→Remix
remix中的合约例子
此外，老师的例子开头处，比我的多了两行，导入其它文件。分别是导入github上的文件，和导入本地的文件。
import "github.com/ethereum/dapp-bin/library/iterable-mapping.sol";
import "./test.sol";
1.3.2 solidity中的注释
有三种。
/*注释*/，类似于C语言中的注释；
//注释，类似于C++中的注释；
///注释，也可以三个斜杠，主要用于函数前，说明函数作用。
1.3.3 remix的使用
remix是一个强大的IDE（Integrated Development Environment ，集成开发环境）。
中间是代码区，右边有六个表单。
- Compile
编译，可以设置为自动编译，修改后自动执行。
Detail按钮可以查看该程序的详细信息。点开弹出。其中，METADATA是该程序的元数据，含有编译器的版本，和其它的一些数据等。这里关注一下ABI数据。它是关于接口的，点开具体的接口，可以看到接口的名字，输入和输出等。
- Run
运行代码。
它提供了三种运行环境，自己练习可以选用JavaScript VM，在本地运行，速度快。它自动提供了5个账号，每个都含有100ETH。Gas limit是发起合约的Gas上限；Value是发送以太币到一个合约时发送的数量。
Deploy布署一个合约。代码区的下面，有控制台可以看到合约执行情况。
-
Settings
设置。主要是设置编译器的版本。 -
Analysis
分析。主要是一些安全性的分析，比如Gas的数量，使用情况；还有一些杂项。 -
Debugger
调试。后面在具体的例子中再介绍。 -
Support
2、ERC 20 规范
前面介绍的DApp例子中，大部分使用了ERC 20 规范。
官方文档：ERC20规范
这个规范有六个接口是强制必须实施的。
- totalSupply()总的供给量
- balanceOf(address tokenOwner)查询某一地址的余额
- approve(address spender, uint tokens) 代币拥有者授权某地址，可以在未来多次从拥有者的账户使用代币。它有一点安全问题，即授权数量要改变时，需要先改为零，再改为更改的值。
- allowance(address tokenOwner,address spender)查询操作，查询一个代币的拥有者，还可以允许支出者花费多少代币。这个跟前面的approve有关。
- transferFrom(address from, address to,uint tokens) 授权的地址从拥有者那里花费代币，也和approve结合使用。花费的数量要小于授权的数量，如果大于则失败；地址输入错误，也会失败。
- transfer(address to, uint tokens) 转移代币，把自己的代币移给目标地址。
还有三个可选操作。name() , symbol(), decimals()，分别是名称，符号，可以分割的程度，如18，1ETH可以分割为10^18份。
还有两个事件。event Transfer(address from, address to, uint256 value)，event Approval(address owner, address spender, uint256 value)，分别是记录Transfer和Approval的操作。
ERC20本质说明
说明一下ERC20规范的本质。它其实是维护了两张表。
一张是每个地址对应了多少代币，如左图。所有余额加起来就是总的供给量。转移代币是把一个地址的余额减少一定的数值，另一个地址增加相应的数值。查询余额就是从这张表中查询。
另一张表是如右图的样子，包含了许可的账户及许可额。再说明一下许可（Approval）的意义。假如合约A调用合约B，如果在调用前直接把代币打到B，B收到币后会有不执行合约的风险，因此不能先直接给B转移代币。ERC20的做法是分为两步，先授权B一定额度的代币，B执行时，从A那里支取代币。因为额度预先分配了，所以转移会成功。
3、ERC 721 规范
官方文档：ERC721规范
ERC 20 和ERC 721 的不同，可以做一个类比。ERC 20 可以类比为现实中的钱币，你的5块钱和我的5块钱是等价的，没有什么不同。我们的钱还都可以再细分。而ERC 721，主要是用在游戏中的道具，比如以太坊中的加密猫游戏，你的猫和我的猫是不一样的。我们的猫也不能分割为半只猫。每只猫都有不同的特性，是非同质的。
在数据结构上，其本质与ERC 20 没有太大的区别，也是维护两张表。具体内容如下。
- balanceOf(address tokenOwner) 一个地址下的余额；
- ownerOf(uint256 tokenId) 从一个ID查询其主人是谁；
- safeTransferFrom(address from, address to, uint256 tokenId, bytes data) 转换操作，把代币转移到合约；
- safeTransferFrom(address from, address to, uint256 tokenId) 转换操作，把代币转移到地址；
- transferFrom(address from, address to, uint256 tokenId) 传统的转移方式；
3、4和5两种方式的区别，5不检查接收者是否为一个合约地址，而3和4会检查接收者是否为合约地址，还会校验地址。
-
approve(address approved, uint256 tokenId) 授权某一地址一定的代币；
-
METADATA (Name, SYM, URI) 元数据：名称，符号，超链接。链接可以指向一张图片，如加密猫的外观图。
-
setApprovalForAll(address operator, bool approved) external; 允许一个地址完全控制自己的代币；
-
getApproved(uint256 tokenId) 查询哪个账户有一个ID的许可权；
-
isApprovedForAll(address owner, address operator) 查询一个地址是否拥有一个地址所有的操作权。
还有三个事件，对应操作发生时负责记录下日志。
- event Transfer(address indexed from, address indexed to, uint256 tokenId)
- event Approval(address owner, address _approved, uint256 _tokenId)
- evnet ApprovalForAll(address owner, address operator, bool approved)
总结一下，这节课主要介绍了智能合约结构、ERC20、ERC721规范，还简要介绍了Remix的使用。
不足之处，请批评指正，感谢。
网友评论