ERC-902: Token Validation

简单概要

用于提供 Token 所有权和转移验证服务的协议。

摘要

本标准提供了一个注册合约方法，用于授权 Token 转移。本质上，这涵盖了最初向用户发行 Token（即：从合约转移到所有者）、在用户之间转移 Token 以及 Token 支出。

动机

资产 Token 化应用广泛，尤其是在证券和 Token 等金融工具中。大多数司法管辖区对可以交易的内容以及可以持有被视为证券的此类 Token 施加了法律限制。广义上讲，这包括 KYC 和 AML 验证，但也可能包括基于时间的支出限制、交易总额等。

监管机构和受制裁的第三方合规机构需要某种方式将链下合规信息（如身份和居住地）链接到链上服务。这种设计的应用范围比法律法规更广泛，包括用于创建、管理和交易 Token 的各种业务逻辑权限。

与其让每个 Token 维护自己的白名单（或其他机制），不如共享链上资源、规则、列表等等。人们还希望聚合分布在多个验证器中的数据和规则，或者应用复杂的行为（例如，切换逻辑、门、状态机）以将分布式数据应用于应用程序。

规范

TokenValidator

interface TokenValidator {
    function check(
        address _token,
        address _subject
    ) public returns(byte statusCode)

    function check(
        address _token,
        address _from,
        address _to,
        uint256 _amount
    ) public returns (byte statusCode)
}

方法

check/2

function check(address _token, address _subject) public returns (byte _resultCode)

参数

• _token: 正在审查的 Token
• _subject: 要检查的用户或合约

返回值 ERC1066 状态码

check/4

function check(address token, address from, address to, uint256 amount) public returns (byte resultCode)

参数

• _token: 正在审查的 Token
• _from: 在转账的情况下，谁放弃 Token 所有权
• _to: 在转账的情况下，谁接受 Token 所有权
• _amount: 正在转移的 Token 数量

返回值 ERC1066 状态码

ValidatedToken

interface ValidatedToken {
    event Validation(
        address indexed subject,
        byte   indexed result
    )

    event Validation(
        address indexed from,
        address indexed to,
        uint256 value,
        byte   indexed statusCode
    )
}

事件

Validation/2

event Validation(address indexed subject, byte indexed resultCode)

从调用 TokenValidator.check/2 返回时，必须触发此事件。

参数

• subject: 被检查的用户或合约
• statusCode: ERC1066 状态码

Validation/4

event Validation(
    address indexed from,
    address indexed to,
    uint256 amount,
    byte   indexed statusCode
)

从调用 TokenValidator.check/4 返回时，必须触发此事件。

参数

• from: 在转账的情况下，谁放弃 Token 所有权
• to: 在转账的情况下，谁接受 Token 所有权
• amount: 正在转移的 Token 数量
• statusCode: ERC1066 状态码

理由

本提案在任何金融 Token 的基础上增加了一个金融权限系统。此设计不是通用的角色/权限系统。在任何系统中，您对调用函数的上下文了解得越多，您的函数就越强大。通过将自己限制在 Token 转移（例如 ERC20 或 EIP-777）中，我们可以假设验证器需要处理的用例类型，并且可以使 API 既小巧、有用又可扩展。

这些事件由调用 Token 触发。由于 Validators 可能会聚合或委托给其他 Validators，因此如果这是 Validator 的责任，将会生成许多无用的事件。这也是为什么我们在 call/4 参数中包含 token 的原因：Validator 无法依赖 msg.sender 来确定调用所涉及的 Token。

我们还从 R-Token 中看到了类似的设计，它使用了一个附加字段：spender。虽然这有一些潜在的用例，但它还不够广泛，无法证明每次调用都传递一个虚拟值是合理的。相反，这样的调用看起来更像这样：

function approve(address spender, uint amount) public returns (bool success) {
    if (validator.check(this, msg.sender, spender, amount) == okStatusCode) {
        allowed[msg.sender][spender] = amount;
        Approval(msg.sender, spender, amount);
        return true;
    } else {
        return false;
    }
}

还需要第二个 check/2 函数，它用途更广泛，不指定转移金额或接收者。这适用于一般检查，例如检查角色（管理员、所有者等），或者用户是否在简单的白名单上。

我们已经将关联的 Validator 地址公开、私有或硬编码的决定留给实现者。拟议的设计不包括集中式注册表。它也不包括 Validated 合约的接口。一个 Token 可能需要一个或多个用于不同目的的 Validators，对于不同的目的需要不同的验证，或者只需要一个 Validator。潜在用例太多，无法提供单一的统一方法集。我们在此处提供了 一组示例合约，可以从这些合约继承以用于常见用例。

byte 返回中的状态代码未指定。可以使用任何状态代码方案，但即将出台一个通用状态代码提案。

通过仅定义验证检查，该标准与 ERC-20、EIP-721、EIP-777、未来的 Token 标准、中心化和去中心化交易所等等广泛兼容。

实现

参考实现

版权

在 CC0 下放弃版权和相关权利。

Citation

Please cite this document as:

Brooklyn Zelenka (@expede), Tom Carchrae (@carchrae), Gleb Naumenko (@naumenkogs), "ERC-902: Token Validation [DRAFT]," Ethereum Improvement Proposals, no. 902, February 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-902.