以太坊开发实战(第四部分:代币及ERC标准)

从开发人员的角度来看,以太坊的代币只是智能合约。若以饮品作比喻,那么这个令牌就可以是咖啡,并且所有人都可以根据他们的喜好进行定制。

你可能听说过ERC20,ERC721或其他标准。 这些只是开发人员社区同意采用的一组基本功能。 无论你喜欢什么,都没有人会阻止你使用自己的功能,并创建一个脚本来管理虚拟货币。

一条来自加勒比海盗的名言在这种情况下应用的非常好:

但是遵循一个标准具有很多你不应忽视的优点。 首先,当你制作一个符合标准的令牌时,每个人都会知道你的令牌的作用以及如何与它进行交互,因此会更加信任它。 像Mist这样的DApps(分布式应用程序)会将其视为一种令牌,并将以特殊的用户界面显示它。此外,你可以发现已经由社区编写好的关于令牌(智能合约)的泛型(Generic)实现。例如OpenZeppelin的框架,许多专家都对其进行了很好的测试,并为你提供了一个可靠的起点。

在本教程中,我们将从头开始编写一个基本的,不完整的ERC20令牌,然后我们将它转换成一个与其完全不同的ERC721令牌,以便我们可以看到两者之间的差异。

这样做的原因是,你会理解一个令牌是如何工作的,它不是一个封闭的黑盒子,而且ERC20是迄今为止工作了两年的公认标准,如果你只是运行一些命令来立即从框架中创建令牌的话,它会有无法预料的点。

Let’s make our token (让我们来做我们的令牌)

ERC20的创建标准化了可互换的令牌,以便其他应用可以重新使用它们:例如从钱包应用到分布式交易。

统一一下意味着它可以与相同类型的令牌互换,换句话说,所有令牌都是相同的(如金钱,一美元与任何其他美元相同)。 一个不可替代的令牌将代表一种独特的资产(如房屋,财产,艺术品等)。 虽然可替换令牌本身具有价值,但不可替代的令牌只是智能合约中资产的一种表示形式。

要制作符合ERC20的令牌,我们必须实现以下功能和事件:

这个标准没有提供这些函数的主体,这是因为你可以按你的喜好编写它们,而且如果你不想支持某些函数的话,在标准范围内返回null/false也是可以的。

注意:在本教程中,理解内容比复制代码更为重要,完整的示例将在本教程结束时给出链接。

Implementation (履行)

首先,我们要给我们的令牌想一个名字,所以我们将使用一个公共变量:

然后给它一个符号:

当然还有小数位数:

由于Solidity不完全支持定点数字,因此你需要将所有数字以整数形式展现。 现在,当您使用2位小数时,“123456”的值将为“1234.56”令牌,如果使用4位小数,则“123456”的值为“12.3456”。 当你不希望你的令牌是“可分割”时,可以使用0作为小数位数。 Ether(以太坊加密货币),使用18位小数。

通常情况下,你都不要用超过18位的小数,除非你想让世界另一方的专家告诉你自己有多愚蠢,并且问你为什么要使用超过18位的小数,然后告诉你为什么18是圣数,因为以太使用18位小数。

我们会计算令牌的总供应量,并记录每个人有多少令牌:

当然,你会从0开始,除非你在令牌智能合约的构造函数中产生一些令牌,例如:

“totalSupply()”函数只是“totalSupply”变量的一个getter:

“balanceOf()”函数也是一样:

现在,真正神奇的是在“transfer()”函数中,这是一个可以将一个令牌发送到另一个令牌的地址。

这实际上是ERC20令牌的核心。

“approve()”,“transferFrom()”和“allowance()”功能也是使令牌ERC20兼容的一部分,但它们很容易受到攻击。

当一个地址“approve()”另一个地址时,已经批准的地址可以从将要批准地址所代表的余额中使用“transferFrom()”来转移一些令牌, “allowance()”只是一个getter函数,用于查看地址可以从另一个地址的余额中“transferFrom()”转移多少。

这些功能实际上代表了安全问题,因为当一个地址批准了另一个地址转移X个令牌,并且由于种种原因决定将这个数量升至或降至Y时,已获批的地址可以在更改补贴的交易执行前迅速地转移第一次补贴的X个令牌。在交易执行后,已获批地址可以再次转移Y个新的已批准的令牌。批准的地址可以快速地将第一个许可的X令牌执行更改补贴的交易,并且在执行后,批准的地址可以再次转移Y新批准的令牌。 我在最后几部分中表示,交易被挖掘时没有把握,当一些交易被执行时,矿工可以稍微篡改。

现在,建议使用一些更安全的“transferFrom()”实现来使该函数更具防故障功能(如上所述,该标准仅仅是一堆函数和预期行为的原型,并且由你来编写主体)。 目前因为ERC20还存在其他缺陷,所以正在讨论一些其他提案。。 其中的两个命题是ERC223和ERC777。

ERC223提案背后的目的是避免将令牌发送给不支持使用这些令牌的错误地址或合同,因为就像第223期以太坊征求意见征询中所述的那样曾经因为这个而丢失了百万美元。 ERC777提案试图通知它将接收的令牌的接收地址等等。 ERC777提案在社区內势头正盛,很有可能取代ERC20。

ERC721

现在,ERC721与ERC20及其家族从根本上是完全不同的。

在ERC721中,令牌是独一无二的。 ERC721是在几个月前提出的,它变得有名是因为CryptoKitties的实行,这是一种人们收集虚拟猫的游戏,这些猫在运行游戏的智能合约中使用的是不可替代的令牌。

现在,如果我们想要将ERC20转换为ERC721,那么我们需要了解第二个提案如何跟踪令牌。

在ERC20中,每个地址都有一个令牌余额。 在ERC721合同中,每个地址都会有一个令牌列表:

由于Solidity有其局限性,并且对于数组没有“indexOf()”方法,所以我们必须手动跟踪所有者数组中的令牌:

当然我们可以执行我们自己的库,它可以找到元素的索引,但是考虑到可能需要长时间运行的循环,还是最好使用映射。

当然,为了轻松跟踪令牌,我们可以添加一个绘图来显示每个令牌的所有者:

这就是两个提议管理令牌的所有不同之处。

ERC721提案中的“transfer()”函数将为令牌设置一个新的所有者:

这个代码虽然较长,但这是移动令牌的一个必要步骤。

还有一点不能忘的是,ERC721也有“批准()”和“transferFrom()”这两种方法,所以在我们传输函数的功能中,我们必须在我们的“transfer()”方法中添加其他指令,这样被批准的令牌在有新的拥有者后就不能再移动该令牌,如下所示:

Minting(造币)

我们将使用通常名为“Mint()”的函数,它可以应用于ERC20和ERC721令牌,因为我们希望可以生成更多可替换令牌,或者创建一个新的不可替代的令牌。

我们用一个任意数字创建一个新的令牌。 然后根据你的使用情况,有时候你可能只想授权某些地址能够在合同中创建新的令牌。

这里需要注意的很重要的一点是,尽管标准接口上没有“mint()”函数,但我们添加了它,就像我们可以添加其他函数来增强和添加更多功能到我们的令牌一样。 例如,我们可以添加购买和销售令牌的系统以获得一定数量的乙醚,或者删除我们不再需要的令牌的功能。

Metadata(元数据)

现在,我们都说不可互换的令牌是一种资产,所以在大多数情况下,我们实际上是想要描述那些资产。 那么我们可以使用如下的字符串:

可以看出智能合约是一种认证,而不是包含对象的东西。 例如,你不能将汽车存储在智能合同中,但是你可以很好地存储其车牌或其他合法身份证明。

现在最常用的一种技术就是虚拟资产,它使用IPFS哈希值作为元数据。 IPFS散列是存储在IPFS上的文件的地址。 简而言之,IPFS就像HTTP的洪流版本。 在IPFS上添加文件时,至少会在连接到IPFS网络的一台计算机上始终可用。

虽然可以在IPFS或HTTP链接上访问该文件供所有人查看,但是“所有权证书”智能在智能合同中注册。 这实际上不是编程,而是一个不可互换的令牌的新应用。 这个很热门的应用名字叫“Crypto-collectibles”。

现在,回到我们的代码,关于ERC721提案的最初讨论到目前为止已经有点死了,原来的海报并没有在一段时间内更新这个线索,所以这里将有一个新的延续。 它被称为ERC841,他们将这个不可替代的令牌的名称改为“行为”。

另外还有一个建议ERC821,受到ERC223和ERC777建议和启发,它希望实施更新和更好的设计模式。 ERC821和ERC841试图达到相同的目标,但采用方法的方法有点不同,并且两者都尚未完善,如果您有宝贵意见,可以围绕这两个潜在标准加入讨论。

你可以在这部分的Github仓库中找到ERC20和ERC721的示例实现(但是你不能在生产中使用):

或者最好看看OpenZepplin框架,他们有很好的(大部分)审计和模块化智能合约(当然,在决定使用哪些合约之前,你应该阅读每份合约的内容)。

到此就结束了本系列的第四部分。 在下一个章节中,我们将看到如何创建一个DApp。

如果你喜欢这个教程,你可以@dev_zl来跟我交流。

Bonus:ICOs & Crowdsales (福利:首次令牌发行和众募)

首次令牌发行产品(ICO)虽然有点超出了以太坊项目的发展部分,但实际上,它们只是众筹。

如果一家创业公司需要一些资金,他们会创建自己的令牌,并在一段时间内卖掉一些,这称为众募或ICO。

在智能合约和区块链技术之前,创业公司会使用众筹网站来筹集资金,但这些网站在此过程中通常会收取很高昂的费用。 而现在通过ICO,你可以削减中间人,直接筹集资金。

现如今,跟真正众筹的的项目比,骗局往往更多,所以从投资者的角度来看,你应该警惕在哪里投入资金。 从开发人员的角度来看,众募只是一个智能合约,它从一开始到结束日期会出售一些令牌以换取以太币。 虽然没有标准的方法来实现这一点,但你会发现在OpenZepplin的回购会得到一个很好的实现。 此外,在以太坊的网站上有一个简单的教程。

本文链接:https://hackernoon.com/ethereum-development-walkthrough-part-4-tokens-and-ercs-68645cf2f73e

本文是以太坊开发实战系列文章的第四部分,其他部分参见以下链接。

Part 1:https://cloud.tencent.com/developer/article/1072873

Part 2:https://cloud.tencent.com/developer/article/1077181

Part 3:https://cloud.tencent.com/developer/article/1077296

Part 5:https://cloud.tencent.com/developer/article/1070361

原文链接:https://hackernoon.com/ethereum-development-walkthrough-part-4-tokens-and-ercs-68645cf2f73e

原文作者:dev_zl

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

用不到50行的Python代码构建最小的区块链

本文用不到50行的 Python 代码构建最小的数据区块链,简单介绍了区块链去中心化的结构与其实现原理。

75170
来自专栏Seebug漏洞平台

以太坊合约审计 CheckList 之“以太坊智能合约编码安全问题”影响分析报告

作者:LoRexxar'@知道创宇404区块链安全研究团队 时间:2018年9月6日

18630

内部区块链的优缺点

我经常转发与银行或大型企业实施的区块链实验有关的新闻,并提出这样的疑问:”他们为什么会在这种内部场景使用区块链呢?“

46770
来自专栏区块链大本营

嘿,程序员!手把手教你写出智能合约Hello, World

81690
来自专栏华仔的技术笔记

ugChain技术测评

40450
来自专栏区块链大本营

偷天换日合约易主,地址变脸移花接木——底层函数误用漏洞 | 漏洞分析连载之四

引子:阵有纵横,天衡为梁,地轴为柱。梁柱以精兵为之,故观其阵,则知精兵之所有。共战他敌时,频更其阵,暗中抽换其精兵,或竟代其为梁柱,势成阵塌,遂兼其兵。并此敌以...

11440
来自专栏圆方圆学院精选

【许晓笛】 EOS 智能合约案例解析(3)

这次向大家介绍 eosio.token 智能合约的最后一个文件 —— abi文件。ABI 全称 Application Binary Interface,中文名...

10140

以太坊开发实战(第1部分:智能合约)

智能合约(smart contracts),ICOs, Mist, Metamask, Remix, geth, web3...如果您愿意花一点时间在以太坊的开...

1.7K70
来自专栏区块链入门

【 链安科技】constructor函数使用漏洞

2018年7月12日,成都链安科技(LianAn Technology)智能合约审计小组使用自主研发的VaaS平台对以太坊链上智能合约进行安全审计的过程中,发现...

11230
来自专栏区块链大本营

敢挑战吗?这30个以太坊开发示例,让你成为80万都挖不走的区块链人才!

我曾经买过加密货币,曾试图使用一些丑陋矿机挖矿,看过一些稀稀拉拉的Solidity教程。但不得不承认,在当时,我更偏爱前者,我切身体会到了加密货币的狂热,急切需...

15430

扫码关注云+社区

领取腾讯云代金券