Alert Source Discuss
🚧 Stagnant Standards Track: ERC

ERC-4974: 评级

用于分配和管理数值评级的接口

Authors Daniel Tedesco (@dtedesco1)
Created 2022-04-02
Discussion Link https://ethereum-magicians.org/t/8805
Requires EIP-165

摘要

本标准定义了一个标准化的接口,用于在以太坊区块链上分配和管理数值评级。这允许评级在智能合约中被编纂,并被其他应用程序识别,从而为 token 带来广泛的新用例。

动机

传统上,区块链应用程序主要集中在买卖数字资产上。然而,以资产为中心的模式通常对基于社区的区块链项目不利,正如 2021 年许多基于 EVM 的游戏和 DAO 的付费游戏模式所见。

本提案通过允许将评级分配给合约和钱包来解决这个问题,为区块链应用程序提供了一种新的可组合原语。这允许各种各样的新用例,例如:

  • DAO 中的投票权重:使用此标准分配的评级可用于确定去中心化自治组织 (DAO) 中成员的投票权重。例如,DAO 可以为在为社区做出贡献方面表现出良好记录的成员分配更高的评级,并使用这些评级来确定每个成员在决策过程中的相对影响力。

  • 去中心化游戏生态系统中的经验值:评级可用于跟踪玩家在去中心化游戏生态系统中的进度,并奖励他们实现特定里程碑或目标。例如,游戏可以使用评级向玩家分配经验值,这些经验值可用于解锁游戏中的新内容或能力。

  • 企业客户的忠诚度积分:评级可用于跟踪客户对特定企业或服务的忠诚度,并奖励他们持续的支持。例如,企业可以使用评级向客户分配忠诚度积分,这些积分可以兑换特殊优惠或折扣。

  • 去中心化保险公司的资产评级:评级可用于评估去中心化保险公司中资产的风险状况,并确定向保单持有人提供的保费和承保范围。例如,去中心化保险公司可以使用评级来评估不同类型资产的风险,并为风险评级较低的资产提供较低的保费和较高的承保范围。

本标准受到 EIP-20EIP-721 token 标准的影响,并在其结构、风格和语义方面都借鉴了它们。

规范

本文档中的关键词“必须”,“禁止”,“需要”,“应该”,“不应该”,“推荐”,“可以”和“可选”应按照 RFC 2119 中的描述进行解释。

每个兼容的合约必须实现以下接口:

// SPDX-License-Identifier: CC0

pragma solidity ^0.8.0;

/// @title EIP-4974 评级
/// @dev 参见 https://eips.ethereum.org/EIPS/EIP-4974
///  注意:此接口的 EIP-165 标识符为 #######。
///  必须使用非 `address(0)` 的 `operator` 地址初始化合约。
interface IERC4974 /* is ERC165 */ {

    /// @dev 当 operator 更改时发出。
    ///  当 `operator` 通过任何机制更改时必须发出。
    ///  必须仅由 `setOperator` 发出。
    event NewOperator(address indexed _operator);

    /// @dev 当 operator 发布评级时发出。
    ///  当评级通过任何机制分配时必须发出。
    ///  必须仅由 `rate` 发出。
    event Rating(address _rated, int8 _rating);

    /// @dev 当 operator 删除评级时发出。
    ///  当评级通过任何机制删除时必须发出。
    ///  必须仅由 `remove` 发出。
    event Removal(address _removed);

    /// @notice 任命 operator 权限。
    /// @dev 除非 `msg.sender` 是 `operator`,否则必须抛出。
    ///  如果 `operator` 地址已经是当前的 `operator` 或零地址,则必须抛出。
    ///  必须发出 `Appointment` 事件。
    /// @param _operator 智能合约的新 operator。
    function setOperator(address _operator) external;

    /// @notice 评级一个地址。
    ///  每次成功调用时必须发出一个 Rating 事件。
    /// @param _rated 要评级的地址。
    /// @param _rating 要重新分配的 EXP token 总数。
    function rate(address _rated, int8 _rating) external;

    /// @notice 从地址中删除评级。
    ///  每次成功调用时必须发出一个 Remove 事件。
    /// @param _removed 要删除的地址。
    function removeRating(address _removed) external;

    /// @notice 返回评级地址的评级。
    /// @dev 每次 `Rating` 发出时必须注册。
    ///  对于关于零地址的查询应该抛出。
    /// @param _rated 要查询评级的地址。
    /// @return int8 分配的评级。
    function ratingOf(address _rated) external view returns (int8);
}

interface IERC165 {
    /// @notice 查询合约是否实现了接口。
    /// @dev 接口标识在 EIP-165 中指定。此函数
    ///  使用的 gas 小于 30,000。
    /// @param interfaceID 接口标识符,如 EIP-165 中指定。
    /// @return bool 如果合约实现了 `interfaceID` 并且
    ///  `interfaceID` 不是 0xffffffff,则返回 `true`,否则返回 `false`。
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

原理

评级分配

评级应由合约 operator 自行决定。此方可以是运动队教练或多重签名 DAO 钱包。我们决定不指定治理如何发生,而只指定 治理 发生。这允许比优化特定决策形式更广泛的潜在用例。

本提案标准化了一种控制机制来分配社区声誉,而不鼓励对该认可进行金融化。虽然它不能确保精英管理,但它打开了这扇门。

int8 的选择

它是签名的:审查者应该能够为他们与之交互的钱包和合约提供中性和负面评级。这对于可能受到恶意行为者攻击的去中心化应用程序尤其重要。

它是 8 位的:这里的目的是将评级保持在一些可以理解的比较范围内。从长远来看,这可以鼓励评级的轻松聚合,而不是使用用户可能采用各种各样规模的更大的数字。

评级变更

评级应该允许合约 operator 更新评级。如果 Bob 对社区做出了巨大贡献,但后来被抓到从 Alice 那里偷东西,社区可能会认为这应该降低 Bob 在社区中的地位和影响力。同样,虽然这不能确保社区内的道德标准,但它打开了这扇门。

相关地,评级应该允许删除评级,如果在评估者对其有效评估能力没有信心的情况下撤销评级。

接口检测

我们选择了标准接口检测 (EIP-165) 来公开兼容智能合约支持的接口。

元数据选择

我们在元数据扩展中要求了 namedescription 函数。name 在基于区块链的原语的主要标准中很常见。我们包含了一个 description 函数,该函数可能对具有多个评级系统的游戏或其他应用程序有所帮助。

我们提醒实现作者,如果您反对使用此机制,则空字符串是对 namedescription 的有效响应。我们还提醒大家,任何智能合约都可以使用与您的合约相同的名称和描述。客户端如何确定哪些评级智能合约是众所周知的(规范的)不在本标准的范围内。

缺点

使用此标准的一个潜在缺点是评级是主观的,可能并不总是准确地反映合约或钱包的真实价值或质量。但是,该标准提供了更新和删除评级的机制,从而可以随着时间的推移进行灵活性和演变。

在动机部分中确定的用户强烈需要确定合约或社区如何评估另一个合约或社区。虽然一些用户可能对他们收到的评级感到自豪,但其他用户可能会正确或错误地收到某些合约的负面评级。负面评级可能允许进行邪恶活动,例如欺凌和歧视。我们恳请所有实施者注意他们使用此标准创建的任何评级系统可能产生的后果。

向后兼容性

我们采用了 EIP-20 和 EIP-721 规范中的 name 语义。

参考实现

可以在 assets 文件夹中找到此标准的参考实现。

安全注意事项

此标准的一个潜在安全问题是恶意行为者向合约或钱包分配虚假或误导性评级的风险。这可能被用来操纵 DAO 中的投票权重,或欺骗用户根据不准确的评级做出错误的决定。

为了解决这个问题,该标准包括更新和删除评级的机制,允许在出现虚假或误导性评级的情况下进行更正。此外,使用单个 operator 地址来分配和更新评级提供了一个单一的控制点,可用于执行有关评级分配的规则和规定。

另一个潜在的安全问题是攻击者有可能获得 operator 地址的控制权并利用它来操纵评级以谋取私利。为了降低这种风险,建议仔细管理和保护 operator 地址,并让多个参与方参与其控制和监督。

总的来说,兼容合约的安全性将取决于对 operator 地址的仔细管理和保护,以及制定有关评级分配的明确规则和规定。

版权

版权和相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Daniel Tedesco (@dtedesco1), "ERC-4974: 评级 [DRAFT]," Ethereum Improvement Proposals, no. 4974, April 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4974.