ERC-1921: dType 函数扩展

简述

在 dType 的上下文中，即 EIP-1900 中描述的去中心化类型系统，我们建议在 dType 注册表中添加对注册函数（优先选择 pure 和 view）的支持。

摘要

该提案是旨在扩展去中心化类型系统概念的一系列 EIP 的一部分，如 EIP-1900 中所述。 当前的 EIP 规定了支持注册单个智能合约函数所需的数据定义和接口，作为 dType 注册表中的条目。

动机

为了将 EVM 演变为单例操作系统，我们需要一种注册、查找和寻址我们想要以自动化方式运行的合约函数的方法。 这意味着可以访问在 EVM 中运行函数所需的所有数据。

除了上述动机之外，该提案在不久的将来也会带来好处。拥有一个全局可用、非托管的函数注册表，将使工具的开发民主化，例如那些以以下内容为目标的工具：区块链数据分析（例如区块浏览器）、智能合约 IDE、智能合约的安全分析。

注册新的智能合约函数可以通过与 EIP-1900 提到的相同的共识机制来完成，以避免使用冗余或不正确的记录来加重链状态的负担。

规范

此规范的目标是 pure 和 view 函数。

对于每个函数，我们可以存储：

• name - 类型 string 唯一函数名称，如 EIP-1900 中定义；必需
• types - 每个输入的类型数据和标签，如 EIP-1900 中定义；必需
• outputs - 每个输出的类型数据和标签；必需
• contractAddress - 类型 address - 函数所在的智能合约，如 EIP-1900 中定义；对于接口是可选的
• source - 类型 bytes32 - 对包含函数源代码的外部文件的引用，如 EIP-1900 中定义；可选

因此，此提案将 outputs 添加到 EIP-1900 类型注册定义。

以下是 dType 注册表的函数注册对象的示例：

{
    "name": "setStaked",
    "types": [
        {"name": "TypeA", "label": "typeA", "relation":0, "dimensions":[]}
    ],
    "typeChoice": 4,
    "contractAddress": <已部署的智能合约的地址，函数在其中定义>,
    "source": <用于引用源文件的 bytes32 哈希>,
    "outputs": [
        {"name": "TypeB", "label": "typeB", "relation":0, "dimensions":[]}
    ]
}

上面的对象将被传递给 <dType registry>.insert({...})

为 dType 注册表提出了一个附加的 setOutputs 函数：

function setOutputs(
    bytes32 identifier,
    dTypes[] memory outputs
)
    public

• identifier - 类型 bytes32，类型的标识符，如EIP-1900中所定义
• outputs - 类型 dTypes，如 EIP-1900 中定义

实施建议

在 dType 注册表实现中，outputs 可以存储在一个 mapping 中：

mapping(bytes32 => dTypes[]) public outputs;

理由

建议将每个 pure 或 view 函数视为一个单独的实体，而不是采用基于合约的方法，这样可以：

• 拥有一个现成可用的函数的全局上下文
• 通过函数式编程模式扩展设计，而不是通过合约封装的逻辑（可以成功地用于独立扩展开发工作）
• 双向连接函数与它们使用的类型，使自动化更容易
• 如果其他合约函数未通过社区共识，则从已部署的合约中挑选函数
• 具有范围限制的改进 - 不是重新部署整个合约，我们可以只重新部署我们想要添加到注册表中的新函数版本
• 为共同利益实现对单个函数的细粒度审计
• 直接在生产链上启用测试，而不会产生状态副作用

建议为每个函数在链上存储最小的 ABI 信息，这使我们能够：

• 启用链上自动化（例如，函数链接和组合）
• 如果函数签名格式发生更改（例如，从 bytes4 更改为 bytes32），则向后兼容：可以使用 dType 注册多个签名计算函数。示例：

function getSignatureBytes4(bytes32 identifier)
    view
    public
    returns (bytes4 signature)

function getSignatureBytes32(bytes32 identifier)
    view
    public
    returns (bytes32 signature)

• identifier - 类型的标识符，如EIP-1900中所定义
• signature - 函数的签名

关于此设计的担忧可能是：

• 为属于同一合约的每个函数存储 contractAddress 的冗余

我们认为，由于重用已经注册并且现在很容易找到的类型和函数，因此链上的 DRYness 将补偿状态/存储成本。一旦规范和实现更接近最终确定，将添加其他状态/存储成本计算。

请注意，输入和输出类型基于已注册的类型。这减少了每个函数需要存储的 ABI 信息量，并使开发人员能够聚合和查找对其 I/O 使用相同类型的函数。这可能是互操作性和智能合约组合的强大工具。

向后兼容性

此提案不影响现有的 Ethereum 标准或实现。应完全支持为现有合约部署注册函数。

测试用例

稍后添加。

实现

可以在 https://github.com/pipeos-one/dType 找到正在进行中的实现示例。 当就规范达成共识时，将使用适当的实现更新此提案。

版权

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

Citation

Please cite this document as:

Loredana Cirstea (@loredanacirstea), Christian Tzurcanu (@ctzurcanu), "ERC-1921: dType 函数扩展 [DRAFT]," Ethereum Improvement Proposals, no. 1921, April 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1921.