非抽象合同的supportsInterface实现方法

Question

我有下面的场景。

contract GovernanceERC20 is ERC165Upgradeable, ERC20VotesUpgradeable, {
   
   bytes4 private constant GOVERNANCE_INTERFACE_ID;

   /// @inheritdoc ERC165Upgradeable
    function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {
        return
            interfaceId == GOVERNANCE_INTERFACE_ID ||
            interfaceId == type(IERC20Upgradeable).interfaceId ||
            interfaceId == type(IERC20PermitUpgradeable).interfaceId ||
            interfaceId == type(IERC20MetadataUpgradeable).interfaceId ||
            interfaceId == type(ERC20VotesUpgradeable).interfaceId ||
            super.supportsInterface(interfaceId);
    }
   
   function initialize() public view returns(uint) {
        return 10;
   }

   function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }

   function great() public view returns(uint) {
        return 10;
   }
  
}

正如你所看到的，我在想GOVERNANCE_INTERFACE_ID应该是什么。

方法1:我不能做GOVERNANCE_INTERFACE_ID = type(GovernanceERC20).interfaceId as治理-isn 20‘不是抽象的。

方法2:我不想为GovernanceERC20创建任何接口。

GOVERNANCE_INTERFACE_ID应该是什么？

选项A:

GOVERNANCE_INTERFACE_ID = this.initialize.selector ^ this.great.selector ^ this.mint.selector;

选项B:

GOVERNANCE_INTERFACE_ID = type(IERC20Upgradeable).interfaceId ^ type(IERC20PermitUpgradeable).interfaceId ^ type(IERC20MetadataUpgradeable).interfaceId ^ type(ERC20VotesUpgradeable).interfaceId ^ this.initialize.selector ^ this.great.selector ^ this.mint.selector;

Answer 1

严格地说，只要它不与其他标识符冲突，这并不重要。

您可能知道，EIP-165指定如何确定如何实现接口。它有一个例子：return i.hello.selector ^ i.world.selector;。因此，基本上XORing将其函数的选择器组合在一起。有一个EIP-881，它深入到更多的细节，但它还没有最后确定。

至于选项A和B，选项A更符合接口中ID的计算方式:接口不关心实现什么其他接口，ID只说明该特定接口支持什么。因此，检查多个supportsInterface it以查看实现支持什么功能通常是有用的。从这个意义上说，我赞成备选案文A。

我不知道您为什么不想为您的额外函数添加一个接口，但我仍然会像从接口那样计算ID。因此备选案文A。