EIP-xxxx dType - Extending the Decentralized Type System for Functions #1921
In the context of dType, the Decentralized Type System described in EIP-1900, we are proposing to add support for registering functions in the dType Registry.
This proposal is part of a series of EIPs focused on expanding the concept of a Decentralized Type System, as explained in EIP-1900.
In order to evolve the EVM into a Singleton Operating System, we need a way to register, find and address contract functions that we want to run in an automated way.
Aside from the above motivation, there are also near future benefits for this proposal. Having a globally available, non-custodial functions registry, will democratize development of tools, such as those targeting: blockchain data analysis (e.g. block explorers), smart contract IDEs, security analysis of smart contracts.
Registering new smart contract functions can be done through the same consensus mechanism as EIP-1900 mentions, in order to avoid burdening the chain state with redundant or improper records.
For each smart contract function, we must store:
The first four are handled by EIP-1900.
We can then have an interface to register these optional inputs/outputs for an already registered type, referenced by
We also propose to extend the
An example would be a base
These wrapper functions can be defined in their own library, enabling chaining and composition:
An example of the data object that is given when registering a function:
Note that the input and output types are based on types that have already been registered. This lowers the amount of ABI information needed to be stored for each function and enables developers to aggregate and find functions that use the same types for their I/O. This can be a powerful tool for interoperability and smart contract composition.
The suggestion to treat each function as a separate entity instead of having a contract-based approach allows us to:
The proposal to store the minimum ABI information on-chain, for each function, allows us to:
Concerns about this design might be:
We think that state/storage cost will be compensated through DRYness across the chain, due to reusing types and functions that have already been registered and are now very easy to find. Other state/storage cost calculations will be added once the specification and implementation is closer to be finalized.
This proposal does not affect extant Ethereum standards or implementations. Registering functions for existing contract deployments should be fully supported.
Will be added.
In work implementation examples can be found at https://github.com/ctzurcanu/dType/tree/master/contracts/contracts.
Copyright and related rights waived via CC0.