ERC-2157: dType 存储扩展 - EVM 的去中心化类型系统

简单总结

此 ERC 是 ERC-1900 的扩展，为 dType（一种去中心化类型系统）提出了一种可选的存储扩展，它为所有包含类型实例的存储合约指定了一个通用的 ABI。

摘要

存储扩展将能够轻松地导航和检索旨在公开使用的类型数据。这可以通过标准化 dType 存储合约的 ABI 来实现，从而获得通往类型实例记录的确定性路径。这种标准化使得更有效地使用链上和链下数据成为可能，并为去中心化应用程序开辟了可能性，使开发人员能够在公共全局数据之上进行构建。

动机

目前，以太坊没有数据可寻址性的标准化。对于准私有数据来说，这可能不是必需的，但是，对于公开消费的数据来说，这是必需的。 ERC-1900 已经开始标准化数据类型，以提高项目之间的互操作性，但如果我们想构建一个全球生态系统，这还不够。确定性数据可寻址性将使任何人都可以基于相同的公共数据集（链上或链下）进行构建。

诚然，使用 ERC-1900，链下区块链数据分析和特定于类型的数据检索将成为可能，但这暗示着依赖于中心化数据缓存（区块链浏览器）或维护您自己的数据缓存。此外，此选项不允许链上标准化数据检索路径，因此限制了可以完成的链上可互操作操作的类型。

拥有一种清晰的检索数据的方式，而不是分析区块链中 ABI 或字节码中具有特定类型的合约，这将使针对特定类型的全局数据的应用程序的开发更加容易和去中心化。

例如，一个去中心化的市场可以在一些特定于市场的类型之上构建，并且通过确切地知道类型数据的存储位置，可以很容易地创建自定义算法，为用户提供他们所需的产品信息。每个人都可以访问数据，并且数据路径是标准化的。

此外，通过标准化存储合约接口，可以进行 ABI 推断。通用接口以及 dType 注册表将提供重建 ABI 所需的所有数据。

该系统可以在以后的提案中扩展访问和可变性控制。访问和可变性控制对于公共用途的全局系统是必要的。此外，我们可以对系统组件进行同构的权限应用。本提案未对此进行详细说明。

另一个用例是以太坊分片之间或以太坊与其他链之间的数据桥。分片/链之间的数据同步可以通过编程方式跨数据类型（来自各种项目）完成。想象一下，一个用户在一个链上有一个公共的个人资料/身份合约，希望将该个人资料转移到以太坊上。通过支持原始链类型并拥有标准化的存储机制，数据移动过程将是相同的。

这种分离数据类型定义和存储的模式允许开发人员在以太坊上创建类似函数式编程的模式，即使像 Solidity 这样的语言不是函数式的。

规范

TypeRootContract

ERC-1900 在类型元数据中定义了一个 contractAddress 字段。对于 ERC-1900 的有限目的，该字段包含类型定义存在的以太坊类型库的值。为了本 ERC 的目的，contractAddress 将包含 TypeRootContract 的以太坊地址。

contract TypeRootContract {
  address public libraryAddress;
  address public storageAddress;

  constructor(address _library, address _storage) public {
    libraryAddress = _library;
    storageAddress = _storage;
  }
}

• libraryAddress - 来自 ERC-1900 的类型定义库的以太坊地址
• storageAddress - 类型数据存储合约的以太坊地址

TypeStorageContract

该合约将使用类型库来定义存储在其中的内部数据。每个记录将是一个类型实例，可以通过主标识符寻址。主标识符由类型库的 getIdentifier 函数基于类型实例值计算得出。

我们提出了一种 Solidity CRUD 模式，如 https://medium.com/robhitchens/solidity-crud-part-1-824ffa69509a 中所述，其中记录也可以使用其索引（一个单调递增的计数器）进行检索。

TypeStorageContract 的一个存根实现如下所示：

import './TypeALib.sol';

contract TypeAStorage {
    using TypeALib for TypeALib.TypeA;

    bytes32[] public typeIndex;
    mapping(bytes32 => Type) public typeStruct;

    struct Type {
        TypeALib.TypeA data;
        uint256 index;
    }

    event LogNew(bytes32 indexed identifier, uint256 indexed index);
    event LogUpdate(bytes32 indexed identifier, uint256 indexed index);
    event LogRemove(bytes32 indexed identifier, uint256 indexed index);

    function insert(TypeALib.TypeA memory data) public returns (bytes32 identifier);

    function insertBytes(bytes memory data) public returns (bytes32 identifier);

    function remove(bytes32 identifier) public returns(uint256 index);

    function update(bytes32 identifier, TypeALib.TypeA memory data) public returns(bytes32 identifier)

    function isStored(bytes32 identifier) public view returns(bool stored);

    function getByHash(bytes32 identifier) public view returns(TypeALib.TypeA memory data);

    function getByIndex(uint256 index) public view returns(TypeALib.TypeA memory data);

    function count() public view returns(uint256 counter);
}

理由

我们现在将构建块视为一个智能合约，其中封装了一个对象，该对象包含只能从内部理解的状态更改函数。这更类似于面向对象编程，并带来互操作性和可扩展性问题。不一定针对单个项目，而是针对全球以太坊操作系统。这就是为什么我们建议将数据与业务逻辑和数据结构定义分开。

当您拥有公共聚合数据，并按每种类型进行分类时，任何人都可以基于它构建工具。这与我们在 web2 中发现的封闭或分散的数据模式截然不同。

我们选择定义一个 TypeRootContract 而不是使用 TypeStorage 合约的字段来扩展 dType 注册表，因为这种方法可以在将来更轻松地进行接口更新。它更具可扩展性。

用于 dType 本身和所有 Type Storage 合约的存储模式可以是相同的。这降低了构建、测试和审计代码的成本。

TypeStorageContract 模式应确保：

• 按主标识符进行类型实例寻址
• 一种从合约中检索所有记录的方法
• 统计记录的数量

向后兼容性

本提案不影响现有的以太坊标准或实现。它使用当前实验版本的 ABIEncoderV2。

测试用例

将会添加。

实现

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

版权

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

Citation

Please cite this document as:

Loredana Cirstea (@loredanacirstea), Christian Tzurcanu (@ctzurcanu), "ERC-2157: dType 存储扩展 - EVM 的去中心化类型系统 [DRAFT]," Ethereum Improvement Proposals, no. 2157, June 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2157.