-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address metadata registry #926
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,73 @@ | ||
## Preamble | ||
|
||
EIP: <to be assigned> | ||
Title: Address metadata registry | ||
Author: Nick Johnson <nick@ethereum.org> | ||
Type: Standard track | ||
Category: ERC | ||
Status: Draft | ||
Created: 2018-03-12 | ||
Dependencies: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md | ||
|
||
## Abstract | ||
This EIP specifies a registry for address metadata, permitting both contracts and external accounts to supply metadata about themselves to onchain and offchain callers. This permits use-cases such as generalised authorisations, providing token acceptance settings, and claims registries. | ||
|
||
## Motivation | ||
An increasing set of use cases require storage of metadata associated with an address; see for instance EIP 777 and EIP 780, and the ENS reverse registry in EIP 181. Presently each use-case defines its own specialised registry. To prevent a proliferation of special-purpose registry contracts, we instead propose a single standardised registry using an extendable architecture that allows future standards to implement their own metadata standards. | ||
|
||
## Specification | ||
The metadata registry has the following interface: | ||
``` | ||
interface AddressMetadataRegistry { | ||
function provider(address target) view returns(address); | ||
function setProvider(address _provider); | ||
} | ||
``` | ||
|
||
`setProvider` specifies the metadata registry to be associated with the caller's address, while `provider` returns the address of the metadata registry for the supplied address. | ||
|
||
The metadata registry will be compiled with an agreed-upon version of Solidity and deployed using the trustless deployment mechanism to a fixed address that can be replicated across all chains. | ||
|
||
## Provider specification | ||
|
||
Providers may implement any subset of the metadata record types specified here. Where a record types specification requires a provider to provide multiple functions, the provider MUST implement either all or none of them. Providers MUST throw if called with an unsupported function ID. | ||
|
||
Providers have one mandatory function: | ||
|
||
``` | ||
function supportsInterface(bytes4 interfaceID) constant returns (bool) | ||
``` | ||
|
||
The `supportsInterface` function is documented in [EIP 165](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md), and returns true if the provider implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a provider returns `true` for `supportsInterface()`, it must implement the functions specified in that interface. | ||
|
||
`supportsInterface` must always return true for `0x01ffc9a7`, which is the interface ID of `supportsInterface` itself. | ||
|
||
The first argument to all provider functions MUST be the address being queried; this facilitates the creation of multi-user provider contracts. | ||
|
||
Currently standardised provider interfaces are specified in the table below. | ||
|
||
| Interface name | Interface hash | Specification | | ||
| --- | --- | --- | | ||
|
||
EIPs may define new interfaces to be added to this registry. | ||
|
||
## Rationale | ||
There are two obvious approaches for a generic metadata registry: the indirection approach employed here, or a generalised key/value store. While indirection incurs the cost of an additional contract call, and requires providers to change over time, it also provides for significantly enhanced flexibility over a key/value store; for that reason we selected this approach. | ||
|
||
## Backwards Compatibility | ||
There are no backwards compatibility concerns. | ||
|
||
## Implementation | ||
The canonical implementation of the metadata registry is as follows: | ||
``` | ||
contract AddressMetadataRegistry { | ||
mapping(address=>address) public provider; | ||
|
||
function setProvider(address _provider) { | ||
provider[msg.sender] = _provider; | ||
} | ||
} | ||
``` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Recommend including an example provider as well that at least implements the required There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed, though callers don't need to do the function hashing, just embed the appropriate constants (unless we can trust solidity to optimise those out, even if optimisation is turned off?) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think there is value in showing a user how to do the XOR, hashing and byte chopping in code, and Solidity is the language that we can be certain all readers of these understand. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If Solidity doesn't optimise-away the hashing at compile-time, though, this is going to be a significant waste of gas. Edit: And in any case this is likely something that should be demoed in 165. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would be OK (though not quite as satisfied) with an example written in JS if you think that is more reasonable. Solidity is just the "common language". I would not recommend people actually do the hashing in Solidity with each contract call. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, I don't think this is the place to do it - this is just a user of EIP165; any examples should probably be there. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As a developer who didn't know of EIP 165's prior to reading this EIP, I was surprised to find it lacking an example for the "other side". If you think this EIP should depend on 165, then I recommend including such a dependency in the EIP and indicating how the two are connected to each other. In general, if an EIP doesn't reference any other EIPs, then I assume it can be consumed on its own (which is what I tried to do when reading this EIP) and it seems that your intent is that this EIP is not consumed on its own. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And of course after saying that, I re-read this EIP and found it did mention EIP 165... |
||
|
||
## Copyright | ||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For clarity, recommend including the Solidity code for this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Solidity implements this automatically now.