常见代币协议转账都需要多少笔交易操作？

到以太坊，我们脑海中出现的第一个关键词也许就是“gas费”。如今各大区块链项目主网上线，所用的宣传方向往往也离不开gas这个单词。

居高不下的gas费一直是区块链交易，尤其是游走于币圈各个领域的投资者的一个痛点。

随着区块链项目的增多以及市场规模的扩大，区块链上的交易数目以及平均交易的Gas消耗也随着增加。

Gasnow中Gas价格历史数据

近期，随着市场的起起落落以及主网升级、Layer2解决方案等因素，以以太坊为首的区块链网络gas费持续下降。

那么除了以上因素以外，是否可以从代码或者智能合约设计角度去减少完成特定功能必须的交易数目，从而优化项目以及整个区块链的交易成本和环境呢？

今天本文要为大家介绍的就是这一主题：对比可兼容最常见的代币协议ERC20的几种协议，包括ERC777, ERC1363以及ERC2612。

本文将通过分析几种协议中代币转账操作所需要交易数目，帮助大家发现其中的最优选择！

ERC20

当前完成ERC20协议代币的转账操作需要分两步：approve()以及transfer()/tranferFrom()。

因此必须分成两个交易并支付两份Gas: 即第一个交易完成授权，第二个交易完成转账。 

为了解决“两步走”的问题，当前主要提案有ERC777, ERC1363以及ERC2612，其中前两者已经完善，ERC2612仍在优化阶段。

ERC20中主要的参与者为代币发送者sender以及代币接收者receiver。

下文中将以Alice为代币发送者sender，Bob为代币接收者receiver为例，为大家直观展示操作简要流程图。

ERC20代币转账操作简要流程图

ERC777

ERC777尝试引入operator的概念来规避掉“两步走”的问题。

operator在被sender授权之后，在该ERC777代币合约中，sender可通过operator将代币发送给receiver。

在发送代币的交易中，sender无需支付gas，发送代币交易的gas会由operator支付。

ERC777代币转账操作简要流程图

ERC1363

ERC1363引入启发自ERC20中approve(), transfer()和tranferFrom()的高级函数：approveAndCall()，transferAndCall()和 transferFromAndCall()。

这些函数可以帮助ERC1363协议合约在完成approve()， transfer() 或 tranferFrom()之后，继续执行spender地址处智能合约的onApprovalReceived()方法，以及receiver地址处智能合约的onTransferReceived()方法。

通过这样的方式来将approve和transfer或者其他任何spender或者receiver想要执行的代码链接起来成为一个交易。

ERC1363代币转账操作简要流程图

ERC2612

ERC2612采用了用户签名的方式进行approve，签名中包含了approve的地址以及额度。

用户通过向ERC2162标准的合约提交该签名，然后ERC2162标准的合约通过验证该签名，从该签名中获得approve的地址以及额度，并且在验证成功之后使用验证获得的信息直接触发transferFrom操作，从而最终解决“两步走”的问题。

ERC2612代币转账操作简要流程图

写在结尾

这几类协议对比后，我们发现：

从完成代币发送所需要的交易数目角度看，ERC1363与ERC2612必然是更加合适的选择，其中ERC2612相比ERC1363更加灵活。同时ERC777, ERC1363与ERC2612都兼容ERC20类型合约，因此不存在由兼容性引发的问题。

随着区块链智能合约项目的增多，单个区块的时间内产生的等待交易数目总数随之增加。

如果可以通过协议代码层面减少完成功能需要被打包入区块的等待交易总数，那么对于区块链上的平均的交易速度以及平均gas花费都会有极大的帮助。

交易成本及环境的优化，不仅会促进区块链网络的繁荣，区块链生态及基础设施也会更加完善。