The EVM and related languages such as Solidity need consensus on an extensible Type System in order to further evolve into the Singleton Operating System (The World Computer).
We are proposing a decentralized Type System for Ethereum, to introduce data definition (and therefore ABI) consistency. This ERC focuses on defining an on-chain Type Registry (named dType) and a common interface for creating types, based on structs.
In order to build a network of interoperable protocols on Ethereum, we need data standardization, to ensure a smooth flow of on-chain information. Off-chain, the Type Registry will allow a better analysis of blockchain data (e.g. for blockchain explorers) and creation of smart contract development tools for easily using existing types in a new smart contract.
However, this is only the first phase. As defined in this document and in the future proposals that will be based on this one, we are proposing something more: a decentralized Type System with Data Storage - ERC-2158. In addition, developers can create libraries of pure functions that know how to interact and modify the data entries - dType Functions Extension. This will effectively create the base for a general functional programming system on Ethereum, where developers can use previously created building blocks.
To summarize:
map, reduce, filter, are implemented by each type library.The Type Registry can have a governance protocol for its CRUD operations. However, this, and other permission guards are not covered in this proposal.
The dType registry should support the registration of Solidity's elementary and complex types. In addition, it should also support contract events definitions. In this EIP, the focus will be on describing the minimal on-chain type definition and metadata needed for registering Solidity user-defined types.
A type definition consists of a type library containing:
struct used to define the typeisInstanceOf: checks whether a given variable is an instance of the defined type. Additional rules can be defined for each type fields, e.g. having a specific range for a uint16 amount.map, filter, reducestructureBytes and destructureBytes: provide type structuring and destructuring. This can be useful for low-level calls or assembly code, when importing contract interfaces is not an efficient option. It can also be used for type checking.A simple example is:
Types can also use existing types in their composition. However, this will always result in a directed acyclic graph.
Type metadata will be registered on-chain, in the dType registry contract. This consists of:
name - the type's name, as it would be used in Solidity; it can be stored as a string or encoded as bytes. The name can have a human-readable part and a version number.typeChoice - used for storing additional ABI data that differentiate how types are handled on and off chain. It is defined as an enum with the following options: BaseType, PayableFunction, StateFunction, ViewFunction, PureFunction, EventcontractAddress - the Ethereum address of the TypeRootContract. For this proposal, we can consider the Type Library address as the TypeRootContract. Future EIPs will make it more flexible and propose additional TypeStorage contracts that will modify the scope of contractAddress - ERC-2158.source - a bytes32 Swarm hash where the source code of the type library and contracts can be found; in future EIPs, where dType will be extended to support other languages (e.g. JavaScript, Rust), the file identified by the Swarm hash will contain the type definitions in that language.types - metadata for subtypes: the first depth level internal components. This is an array of objects (structs), with the following fields:
name - the subtype name, of type string, similar to the above name definitionlabel - the subtype labeldimensions - string[] used for storing array dimensions. E.g.:
[] -> TypeA[""] -> TypeA[]["2"] -> TypeA[2]["",""] -> TypeA[][]["2","3"] -> TypeA[2][3]Examples of metadata, for simple, value types:
Composed types can be defined as:
Composed types can be further composed:
myToken type will have the final data format: (address,(string,uint256)) and a labeled format: (address token, (string accountName, uint256 amount)).
To store this metadata, the dType registry will have the following data structures:
For storage, we propose a pattern which isolates the type metadata from additional storage-specific data and allows CRUD operations on records.
Note that we are proposing to define the type's primary identifier, identifier, as keccak256(abi.encodePacked(name)). If the system is extended to other programming languages, we can define identifier as keccak256(abi.encodePacked(language, name)).
Initially, single word English names can be disallowed, avoiding name squatting.
The dType registry interface is:
Notes:
To ensure backward compatibility, we suggest that updating types should not be supported.
The remove function can also be removed from the interface, to ensure immutability. One reason for keeping it would be clearing up storage for types that are not in use or have been made obsolete. However, this can have undesired effects and should be accompanied by a solid permissions system, testing and governance process. This part will be updated when enough feedback has been received.
The Type Registry must store the minimum amount of information for rebuilding the type ABI definition. This allows us to:
There is one advantage that has become clear with the emergence of global operating systems, like Ethereum: we can have a global type system through which the system’s parts can interoperate. Projects should agree on standardizing types and a type registry, continuously working on improving them, instead of creating encapsulated projects, each with their own types.
The effort of having consensus on new types being added or removing unused ones is left to the governance system.
After the basis of such a system is specified, we can move forward to building a static type checking system at compile time, based on the type definitions and rules stored in the dType registry.
The Type Library must express the behavior strictly pertinent to its defined type. Additional behavior, required by various project's business logic can be added later, through libraries containing functions that handle the respective type. These can also be registered in dType, but will be detailed in a future ERC.
This is an approach that will separate definitions from stored data and behavior, allowing for easier and more secure fine-grained upgrades.
This proposal does not affect extant Ethereum standards or implementations. It uses the present experimental version of ABIEncoderV2.
Will be added.
An in-work implementation can be found at https://github.com/pipeos-one/dType/tree/master/contracts/contracts. This proposal will be updated with an appropriate implementation when consensus is reached on the specifications.
A video demo of the current implementation (a more extended version of this proposal) can be seen at https://youtu.be/pcqi4yWBDuQ.
Copyright and related rights waived via CC0.