什么是erc777?

ERC777与ERC20都是一类的合约，都是fungible tokens的一种标准。并且ERC777是对ERC20兼容的，ERC20中的相关操作在ERC777中都能够实现，并且ERC777还提供了更加复杂的操作，还在ERC20的不足的地方进行了改善提升。可以说ERC777是在ERC20的基础上进行的升级改造，但是由于ERC777出现的时间较晚，现在市场上主流的货币还是使用的ERC20，但是这并不能否定ERC777相比于ERC20更高效与更安全。详情可以查看https://docs.openzeppelin.com/contracts/4.x/erc777.

ERC777的不同之处

相较于ERC20，ERC777的改变有以下几个方面：

• 去除了精度的设置
  • 这个说法并不是说ERC777没有了精度，而是在合约中直接限定了精度为18，这样的操作简化了在部署合约时需要进行精度设置，避免出现精度忘记设置或者设置错误的情况。
• 引入了默认操作者defaultOperators()
  • 默认操作者的引入，相当于一个超级用户，该操作者可以对所有的账户进行发送和销毁操作，并且额度等于账户的余额。默认操作者的声明只可以可以在部署函数时创建。当然也不用担心，如果想对某个账户进行额度批准的话，也是可以直接使用approve来进行额度的授权。并且账户也可以调用revokeOperator的方法将默认操作者的权限去除。
• 引入了hook（钩子）函数
  • hook，钩子函数。能够不用通过其他的额外沟通直接将代币转入一个实现了对应接口的合约地址，仅仅只是通过一个调用即可。但是相同的操作在erc20中，理想情况下需要两个call。第一个是用发起方使用一个approve批准合约地址能够调用的金额，第二个是被批准的合约地址进行transfer操作将token转入自己的地址。这只是很理想的状态，这其中混乱的地方在于被批准的合约只有被批准才能进行成功转移，而在这个过程中就会产生繁琐的交流，这是很没有必要的。

hook钩子函数

个人认为在ERC777中最具有特点的的就是hook函数，hook函数在一定程度上保护了用户的财产安全。相比于ERC20来说，在使用ERC20进行转账时，我们无法确定接受的账户的类型，并且无法确定账户的状态，即为无法确定账户是否为一个合约黑洞。

• 合约黑洞指的是接受token的地址是一个合约地址，并且该合约并不会提供任何转移token的方法。即为token被销毁的意思。同时账户的地址也可以成为黑洞，当一个账户的私钥不被任何人知道的时候，这个地址也成为了黑洞地址，平常在进行token销毁时，销毁的地址为address(0)也是黑洞地址。

所以可能会导致用户财产损失。但是ERC777的hook函数就避免了这个问题，erc777在交易中会通过hook函数对接收的地址进行一个审查，查看其是否有ERC777TokensSender接口，预防了合约黑洞的出现。并且在要求某个合约地址发送token是hook函数也会查看其是否实现了ERC777TokensRecipient接口。

那么此时我们会产生一个疑问hook函数如何确认是否接收的合约实现了接口？

• 使用了ERC1820_REGISTRY.getInterfaceImplementer(to, _TOKENS_RECIPIENT_INTERFACE_HASH),进行接收接口验证
• 使用了ERC1820_REGISTRY.getInterfaceImplementer(from, _TOKENS_SENDER_INTERFACE_HASH),进行发送的接口验证

通过IERC1820Registry的getInterfaceImplementer(address account, bytes32 _interfaceHash),通过将方法名进行哈希之后，在一个全局注册表（一个双重嵌套映射）中进行查询mapping(bytes32 => mapping(address => bool)) private _supportedInterfaces;，查看对应地址的合约是否实现了相应的接口，返回一个true或false。 详情可以查看:https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.0/contracts/utils/introspection/ERC1820Implementer.sol。

相较于openzeppelin提供的方法，我们来看一下ERC1820提供的验证的方法在ERC1820中则是提供了两种接口的验证方法. 详情可以查看:https://eips.ethereum.org/EIPS/eip-1820#interface-implementation-erc1820implementerinterface

• mapping(address => mapping(bytes32 => address)) internal interfaces;
• 在全局注册表中（一个双重映射）查看验证的合约是否调用了其他的实现了相应方法的合约
• 在全局注册表中（一个双重映射）查看验证的合约是否实现了相应的接口

我们来观察两种不同的验证方法，ERC1820中提供了更全面跟广泛的验证方式，简化了再写合约时的复杂操作而OpenZeppelin中的验证方法相当于是ERC1820的一刀切，强制要求合约必须实现相应的方法，禁止调用其他合约来替代。这样做增强了安全性并且便于直观的去理解。

额外的问题

如果只是通过查看方法名的哈希值，那么写一个相同的方法名，参数一致，但方法内不执行任何操作会不会形成一个合约黑洞？

• 通过方法名进行哈希的比较，如果存在相同的实现函数的话就会默认该合约实现了相应的接收或者发送的方法。如果存在只实现方法名，但是方法内部不想进行任何操作的话，在查询时也会默认实现了方法名。但是在实际发送或者接收时，会失败从而状态回滚。

结尾

ERC777相比于ERC20而言提高了交易的安全性，和交易的效率。极大的保护了用户的权益，这样的对于一个新手用户来说是很友好的。并且ERC777的产生也代表着，技术在发展，每一个协议都需要进行更多的考虑更多的更新换代，朝着跟方便更安全的方向发展。