From d5aa8954b37bea2318a7a6f70fb6ad220b130f7d Mon Sep 17 00:00:00 2001 From: Wenjing Yu Date: Sun, 23 Jul 2023 17:17:11 -0700 Subject: [PATCH 1/4] Add new EIP: Multi-Namespace Onchain Registry --- EIPS/eip-7406.md | 155 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 EIPS/eip-7406.md diff --git a/EIPS/eip-7406.md b/EIPS/eip-7406.md new file mode 100644 index 00000000000000..233b55fd56580c --- /dev/null +++ b/EIPS/eip-7406.md @@ -0,0 +1,155 @@ +--- +eip: 7406 +title: Multi-Namespace Onchain Registry +description: An universally accepted multi-namespace registry with mapping structures on the Ethereum +author: Mengshi Zhang (@MengshiZhang), Zihao Chen (@zihaoccc) +discussions-to: https://ethereum-magicians.org/t/eip-7406-multi-namespace-onchain-registry/15216 +status: Draft +type: Standards Track +category: ERC +created: 2023-07-23 +--- + +## Abstract + +This EIP proposes a universally accepted description for onchain registry entries with support for multi-namespaces, where each entry is structured as a mapping type. The multi-namespace registry enables the storage of a collection of key-value mappings within the blockchain, serving as a definitive source of information with a traceable history of changes. These mapping records act as pointers combined with onchain assets, offering enhanced versatility in various use cases by encapsulating extensive details. The proposed solution introduces a general mapping data structure that is flexible enough to support and be compatible with different situations, providing a more scalable and powerful alternative to current ENS-like registries. + +## Motivation + +Blockchain-based registries are fundamental components for decentralized applications, enabling the storage and retrieval of essential information. Existing solutions, like the ENS registry, serve specific use cases but may lack the necessary flexibility to accommodate more complex scenarios. The need for a more general mapping data structure with multi-namespace support arises to empower developers with a single registry capable of handling diverse use cases efficiently. + +The proposed multi-namespace registry offers several key advantages: + +- **Versatility**: Developers can define and manage multiple namespaces, each with its distinct set of keys, allowing for more granular control and organization of data. For instance, single same key can derive as different pointers to various values based on difference namespaces, which a namespace can be specified as a session type, if this registry stores sessions, or short URL -> full URL mapping is registry stores such type of data. +- **Traceable History**: By leveraging multi-namespace capabilities, the registry can support entry versioning by using multi-namespace distinct as version number, enabling tracking of data change history, reverting data, or data tombstoning. This facilitates data management and governance within a single contract. +- **Enhanced Compatibility**: The proposed structure is designed to be compatible with various use cases beyond the scope of traditional ENS-like registries, promoting its adoption in diverse decentralized applications. + +## Specification + +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. + +### **Registry specification** + +The multi namespace registry contract exposes the following functions: + +```solidity +function owner(bytes32 namespace, bytes32 key) external view returns (address); +``` + +- Returns the owner of the specified **key** under the given **namespace**. + +```solidity +function resolver(bytes32 namespace, bytes32 key) external view returns (address); +``` + +- Returns the resolver address for the specified **key** under the given **namespace**. + +```solidity +function setOwner(bytes32 namespace, bytes32 key, address newOwner) external; +``` + +- Transfers ownership of the **key** under the specified **namespace** to another owner. This function may only be called by the current owner of the **key** under a specific **namespace**. The same **key** under different **namespaces** may have different owners. A successful call to this function logs the event **Transfer(bytes32 namespace, bytes32 key, address newOwner)**. + +```solidity +function createNamespace(bytes32 namespace) external; +``` + +- Create a new **namespace** such as a new version or a new type of protocol in current registry. A successful call to this function logs the event **NewNamespace(bytes32 namespace)**. + +```solidity +function setResolver(bytes32 namespace, bytes32 key, address newResolver) external; +``` + +- Sets the resolver address for the **key** under the given **namespace**. This function may only be called by the owner of the key under a specific **namespace**. The same key under different namespaces may have different resolvers. A successful call to this function logs the event **NewResolver(bytes32 namespace, bytes32 key, address newResolver)**. + +### **Resolver specification** + +The multi-namespace resolver contract can utilize the same specification as defined in [ERC-137](./eip-137.md): Ethereum Domain Name Service - Specification. + +## Rationale + +The proposed multi-namespace registry addresses the limitations of existing ENS-like registries by offering a more flexible and extensible solution. By supporting multiple namespaces, the registry caters to various use cases, including but not limited to identity management, session management, record tracking, and decentralized content publishing. This flexibility enables developers to design and implement more complex decentralized applications with ease. + +## Backwards Compatibility + +As this EIP introduces a new feature and does not modify any existing behaviors, there are no backwards compatibility issues. + +## Reference Implementation + +### *Appendix A: Registry Implementation* + +```solidity +pragma solidity ^0.8.12; + +import "./IERC7406Interface.sol"; + +contract ERC7406 { + struct Record { + address owner; + address resolver; + } + + + // A map is used to record namespace existence + mapping(byte32=>uint) namespaces; + mapping(bytes32=>mapping(bytes32=>Record)) records; + + event NewOwner(bytes32 indexed namespace, bytes32 indexed key, address owner); + event Transfer(bytes32 indexed namespace, bytes32 indexed key, address owner); + event NewResolver(bytes32 indexed namespace, bytes32 indexed key, address resolver); + event NewNamespace(bytes32 namespace) + + modifier only_owner(bytes32 namespace, bytes32 key) { + if(records[namespace][key].owner != msg.sender) throw; + _ + } + + modifier only_approver() { + if(records[0][0].owner != msg.sender) throw; + _ + } + + function ERC7406(address approver) { + records[0][0].owner = approver; + } + + function owner(bytes32 namespace, bytes32 key) constant returns (address) { + return records[namespace][key].owner; + } + + function createNamespace(bytes32 namespace) only_approver() { + if (status == 0) throw; + NewNamespace(namespace); + if (namespaces[namespace] != 0) { + return; + } + namespaces[namespace] = 1; + } + + function resolver(bytes32 namespace, bytes32 key) constant returns (address) { + if (namespaces[namespace] == 0) throw; + return records[namespace][key].resolver; + } + + function setOwner(bytes32 namespace, bytes32 key, address owner) only_owner(namespace, key) { + Transfer(key, namespace, owner); + records[namespace][key].owner = owner; + } + + function setResolver(bytes32 namespace, bytes32 key, address resolver) only_approver() { + if (namespaces[namespace] == 0) { + this.createNamespace(namespace, 1); + } + NewResolver(key, namespace, resolver); + records[namespace][key].resolver = resolver; + } +} +``` + +## Security Considerations + +The proposed multi-namespace registry introduces several security considerations due to its ability to manage various namespaces and access controls. Thorough testing, auditing, and peer reviews will be conducted to identify and mitigate potential attack vectors and vulnerabilities. Security-conscious developers are encouraged to contribute to the audit process. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 4596f1e1eb3667fd8455ce57aa4964b9a36a355a Mon Sep 17 00:00:00 2001 From: Zihao Chen Date: Tue, 22 Aug 2023 08:39:49 -0700 Subject: [PATCH 2/4] Update EIPS/eip-7406.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-7406.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7406.md b/EIPS/eip-7406.md index 233b55fd56580c..30bf4783cda7cf 100644 --- a/EIPS/eip-7406.md +++ b/EIPS/eip-7406.md @@ -64,7 +64,7 @@ function setResolver(bytes32 namespace, bytes32 key, address newResolver) extern ### **Resolver specification** -The multi-namespace resolver contract can utilize the same specification as defined in [ERC-137](./eip-137.md): Ethereum Domain Name Service - Specification. +The multi-namespace resolver contract can utilize the same specification as defined in [ERC-137](./eip-137.md). ## Rationale From 784c9e26604910f220eb5f7ab0adc1dd20823160 Mon Sep 17 00:00:00 2001 From: Zihao Chen Date: Tue, 22 Aug 2023 08:39:55 -0700 Subject: [PATCH 3/4] Update EIPS/eip-7406.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-7406.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-7406.md b/EIPS/eip-7406.md index 30bf4783cda7cf..1fb01f23e5f0db 100644 --- a/EIPS/eip-7406.md +++ b/EIPS/eip-7406.md @@ -8,6 +8,7 @@ status: Draft type: Standards Track category: ERC created: 2023-07-23 +requires: 137 --- ## Abstract From a3065aa7d4c54fffe69d9b0fd560121a9a4377cb Mon Sep 17 00:00:00 2001 From: Zihao Chen Date: Tue, 22 Aug 2023 08:40:06 -0700 Subject: [PATCH 4/4] Update EIPS/eip-7406.md Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-7406.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7406.md b/EIPS/eip-7406.md index 1fb01f23e5f0db..777f1bc80d60c3 100644 --- a/EIPS/eip-7406.md +++ b/EIPS/eip-7406.md @@ -69,7 +69,7 @@ The multi-namespace resolver contract can utilize the same specification as defi ## Rationale -The proposed multi-namespace registry addresses the limitations of existing ENS-like registries by offering a more flexible and extensible solution. By supporting multiple namespaces, the registry caters to various use cases, including but not limited to identity management, session management, record tracking, and decentralized content publishing. This flexibility enables developers to design and implement more complex decentralized applications with ease. +By supporting multiple namespaces, the registry caters to various use cases, including but not limited to identity management, session management, record tracking, and decentralized content publishing. This flexibility enables developers to design and implement more complex decentralized applications with ease. ## Backwards Compatibility