Add EIP: Interactive across multiple registries #7336
Conversation
File
|
github-actions
bot
added
c-new
eth-bot
changed the title
github-actions
bot
added
w-ci
eth-bot
changed the title
eth-bot
changed the title
May I ask you a kindly reference, please? Thanks |
|
The commit 7dbf5a7 (as a parent of 426ada1) contains errors. |
zihaoccc
force-pushed
the
new_eip
branch
2 times, most recently
from
f4bb42d
to
f366ecc
Compare
|
dear editors, may I ask a kindly review if possible, that will be much appreciated. @axic, @Pandapip1, @SamWilsn, @xinbenlv |
|
|
||
| ## Abstract | ||
|
|
||
| The objective of this EIP is to propose the **Universal Domain Namespace(UDoN)**, which aims to facilitate onchain registry entries. Each entry in this structure adopts a mapping type, allowing for interactive capabilities across multiple registries like [ENS](./eip-137.md) and [NFT accounts](./eip-6551.md). |
There was a problem hiding this comment.
Linking to ERC-6551 creates an implicit relationship between this proposal and that one. That mean ERC-7336 won't be able to advance beyond the status of ERC-6551 (currently Review.) This isn't a problem if it's intended on your part, I just wanted to mention it.
|
|
||
| ## Abstract | ||
|
|
||
| The objective of this EIP is to propose the **Universal Domain Namespace(UDoN)**, which aims to facilitate onchain registry entries. Each entry in this structure adopts a mapping type, allowing for interactive capabilities across multiple registries like [ENS](./eip-137.md) and [NFT accounts](./eip-6551.md). |
There was a problem hiding this comment.
| The objective of this EIP is to propose the **Universal Domain Namespace(UDoN)**, which aims to facilitate onchain registry entries. Each entry in this structure adopts a mapping type, allowing for interactive capabilities across multiple registries like [ENS](./eip-137.md) and [NFT accounts](./eip-6551.md). | |
| The objective of this EIP is to propose the **Universal Domain Namespace(UDoN)**, which aims to facilitate onchain registry entries. Each entry in this structure adopts a mapping type, allowing for interactive capabilities across multiple registries like [ENS](./eip-137.md) and NFT accounts like [ERC-6551](./eip-6551.md). |
|
|
||
| The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. | ||
|
|
||
| **The Universal Domain Namespace(UDoN)** is a singular contract that enables the retrieval of data from multiple registries, each defined under different protocols within its own namespace. These registries employ distinct methods for resolving the key-value pairs. |
There was a problem hiding this comment.
EIPs are generally used to standardize ideas that require interoperability between multiple vendors. If there is a single UDoN registry, it may be more suited to be developed as a service or library as opposed to an EIP.
That's not to say you cannot propose UDoN here, but I would like to see some text in your Motivation that explains why this needs an EIP over some documentation on, for example, a GitHub Pages site.
| ``` | ||
|
|
||
| Smart contracts implementing the standard MUST implement all of the functions in the interface. | ||
|
|
There was a problem hiding this comment.
I don't believe the Specification section is detailed enough to allow an implementer to implement this proposal. There should be enough information here that someone reading this proposal can implement the standard without necessarily having to read the reference implementation.
|
|
||
| ## Rationale | ||
|
|
||
| The rationale behind this EIP is to augment the efficiency and interoperability within the Ethereum ecosystem. It provides a seamless way to interact with different registries, ultimately simplifying the process of reading and retrieving data. This proposed interface will encourage the development of more efficient, interoperable and standardized solutions, leading to a more robust and integrated Ethereum ecosystem. |
There was a problem hiding this comment.
This all reads like Motivation, and should be moved there. The Rationale section is supposed to justify technical decisions made within the EIP itself, while the Motivation justifies the EIP as a whole.
|
|
||
| ## Security Considerations | ||
|
|
||
| Needs discussion. |
There was a problem hiding this comment.
If you include an HTML-style comment, the linter will make sure you replace it before moving to Review:
| Needs discussion. | |
| Needs discussion. <!-- TODO --> |
There was a problem hiding this comment.
We weakly prefer SVG, if you can provide one. If not, that's fine too!
|
I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually. As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process. If there is relevant history here, please link to this PR from the new pull request. On behalf of the EIP Editors, I apologize for this inconvenience. |
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: