A method and system for managing and resolving multiple identities for the metaverse

Abstract

The application provides a meta-universe-oriented multi-identity management and analysis method and system, comprising the following steps: S1, defining the forms, types, type sets, node sets and spaces of identities; S2, building a network architecture of the multi-identity management and analysis system; S3, analyzing the identities in the identity space; S4, parsing domain names through preset identity types to realize the caching and compatibility of domain name system resources; and S5, translating identities in multiple identity spaces. The application can meet the needs of meta-universe-oriented multi-identity management and analysis, can manage multiple identity types across multiple sub-meta-universes at the same time, uniformly manage various identities in the sub-meta-universes, and support functions such as registration, update, revocation and analysis. On this basis, the application can also save storage space and speed up read-write operation speed, can realize privacy protection and access control, and can further meet the needs of decentralization.

Description

Technical Field

[0001] This invention relates to an identifier management and parsing system, more particularly to a multi-identifier management and parsing method for the metaverse, and further to a multi-identifier management and parsing system employing the metaverse-oriented multi-identifier management and parsing method. Background Technology

[0002] The metaverse is currently generally considered a fully immersive, hyperspaced, and self-sustaining virtual shared world. This virtual world consists of a series of interconnected sub-metaverses. Within these sub-metaverses, a user's virtual avatar can access various applications, such as games, social networking, virtual museums, and concerts.

[0003] The metaverse aims to connect everything in the world, including digital twins of physical entities and systems, and user avatars. Therefore, resources in the metaverse include various identities, content, services, and associated data, which constitute the key components of the metaverse's virtual world. Furthermore, to improve user experience, a resource management and resolution system similar to the Domain Name System (DNS) is needed as the infrastructure of the metaverse. The Domain Name System is abbreviated as DNS.

[0004] DNS was initially widely used to address the lack of user-friendliness of IP addresses in traditional TCP / IP network architectures. Traditional DNS maintains the mapping between domain names and IP addresses and provides resolution services to users. Although DNS servers are distributed, root zone management is centralized. This is because the operation of DNS servers depends on a centralized authority, and the recursive resolution of domain names is ultimately determined by the root zone, which is overseen by the Internet Assigned Numbers Authority (IANA) and the Internet Corporation for Assigned Names and Numbers (ICANN). Furthermore, traditional DNS, due to its centralized hierarchical structure, is vulnerable to denial-of-service (DDoS) attacks. Therefore, to avoid the risks of centralization when resolving massive amounts of resources, the architecture of alternative DNS systems should be decentralized, especially when applied in the metaverse.

[0005] Currently, blockchain, as the underlying technology of cryptocurrencies, is a mainstream decentralized technology. With the emergence of blockchain platforms such as Ethereum, blockchain applications have far exceeded the scope of cryptocurrencies. The first blockchain-based DNS system was Namecoin, which implemented traditional DNS functions such as registration, updates, and transmission on cryptocurrency forks. In particular, it was designed as a more universal name-value system, not just an alternative to traditional DNS. It was also the first cryptocurrency-driven solution to solve the long-standing Zooko's triangle problem, creating a naming system that is simultaneously secure, decentralized, and user-friendly. Building upon Namecoin, Blockstack integrated DNS and Public Key Infrastructure (PKI), developing a so-called "virtual chain layer" that achieved good portability. It was the first naming system directly based on the cryptocurrency main chain. To date, the most powerful DNS alternative is Ethereum Name Service (ENS). Unlike classic Ethereum, ENS focuses more on name resolution than identity management. On top of Namecoin, Blockstack, or other similar underlying technologies, DNSChain and Emercoin have further enhanced social or economic implementations, which will not be described in detail here.

[0006] It's important to note that all the aforementioned DNS alternative systems are built on public blockchains. While they offer the advantage of decentralization, several challenges remain when applied to the metaverse. First, public blockchain nodes are permissionless, making it difficult to perform compliance checks on identifiers and their corresponding resource data during consensus. Similarly, illegitimate identifiers and data are difficult to detect. Second, small public blockchains are vulnerable to attacks, so DNS alternative systems should scale up their networks or switch to larger public blockchains using technologies like virtual chains. However, even in cryptocurrency systems, an attacker with only 25% of the network's computing power can potentially launch a 51% attack. Finally, block generation on public blockchains is limited, especially for those employing non-deterministic consensus mechanisms like Proof-of-Work (PoW). While reducing difficulty can increase throughput and reduce latency, it also introduces significant security risks.

[0007] Consortium blockchains introduce certain permissions and authorizations, which, while weakening the decentralized nature of public blockchains, ensure the oversight and trustworthiness of core nodes. Consortium blockchains typically employ deterministic consensus algorithms to improve efficiency and reduce energy consumption. Therefore, for users who value manageability, consortium blockchains are an effective means of achieving both efficiency and security.

[0008] The integration of DNS and consortium blockchains has received relatively little attention from academia. Specifically, to obtain highly reliable domain name resolution results, DNSTSM maintains DNS caching resources on a consortium blockchain. However, this is merely an incremental improvement on traditional DNS and does not address its centralization problem. TD-Root proposes a trusted decentralized DNS root management architecture based on a permissioned blockchain. Ho-Kyung Yang et al. have also proposed a solution for managing content identifiers in a Named Data Network (NDN) environment.

[0009] On the other hand, with the development of new ecosystems and application platforms, the metaverse is gradually evolving into a collection of sub-metaverses centered on humans and encompassing different types of resources. Therefore, the unique identifier of an entity is the core of all identifiers. It natively aligns with the design philosophy of blockchain, which inherently supports identity management. By establishing trusted digital identities within the metaverse, regardless of changes in resource data, their associated encrypted addresses can be traced. In other words, the unique anchor for all entities in the metaverse is their identity. Therefore, managing multiple identifiers through identities within the metaverse is feasible through a blockchain-based DNS alternative system.

[0010] However, most blockchain-based DNS alternatives, such as ENS, manage only a single type of identifier, or manage each type of identifier separately. For example, Blockstack created a new namespace outside of the Domain Name Service to provide PKI and identity management. But this is still insufficient to manage the diverse metaverse of identifiers. Therefore, DNS alternatives must consider the relationships between various identifiers in order to better manage them within the system.

[0011] As one of the existing technologies, Blockstack is a new kind of internet for decentralized applications where users own their own data. Unlike Ethereum, which places user-stored data and the resources (memory, hard drive) needed for program execution on each user's computer, Blockstack runs blockchain programs on daytime servers and stores data locally. It cannot alter, transfer, or revoke user authentication, and cannot read or write user data without permission.

[0012] Blockstack builds a naming system isolated from the underlying blockchain. The underlying blockchain is used to record the state changes of name-value pairs. Utilizing the blockchain's consensus protocol, all operations in the naming system (such as name registration, updates, and transfers) can reach consensus across the entire network and are tamper-proof.

[0013] Blockstack adopts a separation of data plane and control plane, separating naming control from naming-related data. The control plane includes the underlying blockchain and the virtual chain on top of it, defining registered names and creating name-identity binding protocols. The data plane is responsible for data storage, mainly including: (1) zone files used to find data by hash value or URL; (2) external storage (Dropbox, S3, IPFS, etc.). Data is signed by the key pair corresponding to the name it is bound to. Clients read data from the data plane and verify the integrity and reliability of the data using the data hash in the zone file and the name owner's public key.

[0014] This separation of the data plane and control plane allows Blockstack to operate independently of any specific blockchain, meaning users can choose different blockchains based on their needs. However, this existing technology has several drawbacks.

[0015] First, the issue of top-level domain (TLD) allocation remains unresolved: Blockstack is a general-purpose, fully decentralized naming system, not entirely a domain name resolution system; the latter is merely a special application of Blockstack. Therefore, the design of Blockstack did not address the issue of TLD allocation, leading to a proliferation of registered TLDs within Blockstack.

[0016] Second, the resolution efficiency needs to be verified: Blockstack does not have the various caching structures of existing DNS, and the resolution efficiency will decrease as the amount of data to be resolved increases.

[0017] Third, it is heavily reliant on the cryptocurrency blockchain: Blockstack's operation depends on the cryptocurrency blockchain. It writes the pointer to the parsed record into a free field on the cryptocurrency main chain. If other applications also write records into that field on the cryptocurrency main chain, or if the cryptocurrency main chain is adjusted and occupies that field, Blockstack will not be able to function properly.

[0018] Fourth, compatibility with DNS: As a name resolution system, Blockstack can only map object names to addresses one-to-one; it cannot resolve to existing domain name resolution systems. Blockstack competes with and is mutually exclusive with existing domain name resolution systems.

[0019] As another existing technology, Ethereum Name Service (ENS) is a distributed, open, and scalable naming system based on the Ethereum blockchain.

[0020] ENS works by resolving readable domain names (such as "alice.eth") into computer-readable identifiers, such as Ethereum addresses, hashes of content, and metadata. ENS also supports reverse lookup, which makes it possible to associate metadata (such as canonical domain names or API descriptions) with Ethereum addresses.

[0021] ENS shares similar goals with DNS (Internet Domain Name Service), but their architectures differ significantly due to the functional characteristics and limitations of the Ethereum blockchain. Like DNS, ENS is a hierarchical domain name system, with different levels of domain names separated by dots. The names of the levels are called domains, and the owner of a domain has complete control over its subdomains.

[0022] The owner of a top-level domain (such as ".eth" and ".test") is a smart contract called a "registrar," which specifies the rules governing the allocation of subdomains. Anyone can acquire ownership of a domain and use it for themselves by following the rules defined in these contracts.

[0023] Furthermore, due to the hierarchical nature of ENS, regardless of the domain level an individual owns, they can configure subdomains for themselves or others as needed. However, this existing technology has the following drawbacks: Currently, ENS's primary function is to resolve readable domain names, converting them into computer-recognizable identifiers, such as Ethereum addresses and content hashes. Compared to other systems that support multiple identifier resolutions, ENS focuses more on name resolution, but currently only supports managing one type of identifier. If users use different identifiers (such as identity identifiers, geolocation identifiers, etc.), ENS cannot enable mutual access and resource acquisition, which presents certain limitations.

[0024] Therefore, existing technologies only have a single identifier, which cannot meet the needs of multi-identifier management and parsing for the metaverse. Summary of the Invention

[0025] The technical problem to be solved by this invention is to provide a multi-identifier management and parsing method and system for the metaverse, which aims to integrate the identifier types in the current and future networks, provide a unified formal definition structure for these identifiers, and construct a corresponding identifier space; on this basis, it can also manage a multi-identifier blockchain system across multiple sub-metaverses at the same time, so as to meet the needs of the ever-evolving metaverse scenario in the future.

[0026] To address this, the present invention provides a multi-identifier management and parsing method for the metaverse, comprising the following steps:

[0027] Step S1: Define the form of the identifier, the identifier type, the set of identifier types, the set of nodes, and the identifier space.

[0028] Step S2: Build the network architecture of the multi-identifier management and resolution system. Implement the network layer and consensus layer through node classification and lightweight deterministic consensus algorithm, respectively. Implement the index layer or identifier contract through hierarchical index or blockchain Solidity smart contract. Implement the storage layer through distributed encrypted storage related to multi-identifiers.

[0029] Step S3: Perform identifier resolution on the identifier space;

[0030] Step S4: Resolve the domain name using a preset identifier type to achieve caching and compatibility of domain name system resources;

[0031] Step S5: Perform identifier translation between multiple identifier spaces.

[0032] A further improvement of the present invention is that, in step S1, the identifier of the user or device is defined as i. j =type j :identifier_name, where type j (j = 0, 1, 2, ..., k) represents the identifier type, and identifier_name represents the identifier information; the identifier type set is defined as I = {i0, i1, i2, ...}, where i0 represents the identity of the user or device, and {i1, i2, ...} represents various identifiers other than the identity. k It represents a subset of I; the set of nodes is defined as V; the identifier space is defined as a tuple. Among them, I k Represents the identifier space Internal identifier types, It is a subset of the node set V.

[0033] A further improvement of the present invention is that step S1 further includes an identifier space determination process for determining the identifier space. Whether a complete identifier space is constituted in the network includes the following sub-steps:

[0034] Step S101, using the formula Determine the identifier space If the identifier type and node within the network have already been defined, proceed to step S102.

[0035] Step S102, using the formula i0∈I k Determine the identifier space If the set of identifier types contains an identity, proceed to step S103.

[0036] Step S103, using the formula And i j ∈I k Determine the identifier space If the internal node possesses all the identifier types contained in the identifier space, then proceed to step S104.

[0037] Step S104, using the formula if and Determine the identifier space Inside, there is a set I k Do all nodes of the identifier type belong to If yes, then determine the identifier space. It has already formed a complete identifier space in the network.

[0038] A further improvement of the present invention is that step S2 includes the following sub-steps:

[0039] Step S201: The network layer is implemented through node classification. The core network consists of nodes responsible for managing unified level identifiers and processing messages at different levels.

[0040] Step S202: A consensus layer is implemented using a lightweight deterministic consensus algorithm. All blocks are divided into hot blocks, warm blocks, and cold blocks according to their height. Each node of the hot block stores the block information, some nodes of the warm block cache the block information, and the nodes of the cold block only store the block header and erasure code block generated in the warm block. When a block changes from a hot block to a warm block, each node of the warm block first encodes it into a preset number of data blocks and code blocks using erasure coding, and then stores an erasure code block in each node.

[0041] Step S203: Perform hierarchical indexing on the metadata and complete data of the resource to realize the index layer. Save the username table and multiple MIS identifier tables through key-value pairs. Each record in the username table corresponds to a MIS identifier table. The content of the record includes the binding record of multiple identifiers, the hash information of the username and identifier.

[0042] Step S204: A storage layer is implemented by storing complete off-chain resource data related to multiple identifiers. During the storage process, the data owner uses a symmetric key to encrypt the resource data through the MIS processor and encrypts the symmetric key based on the access control policy.

[0043] A further improvement of the present invention is that, in step S204, each sub-universe corresponds to an attribute authorization agency, which is responsible for user authentication and generating the corresponding attribute key.

[0044] A further improvement of the present invention is that step S2 includes the following sub-steps:

[0045] Step S201: The network layer is implemented through node classification. The core network consists of nodes responsible for managing unified level identifiers and processing messages at different levels.

[0046] Step S202: A consensus layer is achieved through proof-of-stake consensus.

[0047] Step S203': Implement identification contracts through blockchain Solidity smart contracts to associate resources with identifications one by one to form identification contracts corresponding to resource types. The identification contracts include identity identification contracts, content identification contracts, and service identification contracts. Each type of identification contract maintains a corresponding identification table. During the identification resolution process, the corresponding identification contract is first selected according to the identification type. Then, the identification contract obtains resource information from the identification table according to the actual identification. Finally, its attributes are checked and the metadata and resource data associated with the identification are accessed.

[0048] Step S204: Implement the storage layer by storing complete off-chain resource data related to multiple identifiers.

[0049] A further improvement of the present invention is that step S3 includes the following sub-steps:

[0050] Step S301: Query the global status table to obtain the metadata address hash (Username+Identifier) ​​and the summary information of the associated resource;

[0051] Step S302: Access the metadata server according to the metadata address and accept a metadata file, the metadata file containing the location of the storage server, access control policy and symmetric key;

[0052] Step S303: After the user receives the metadata file, he requests the encrypted resource data associated with the identifier from the network.

[0053] Step S304: After the user receives the encrypted resource data associated with the identifier, the user first decrypts it using the symmetric key and performs an integrity check based on the digest information. If the check passes, the identifier is considered to have been successfully parsed; otherwise, the user returns to step S303 to continue the request.

[0054] A further improvement of the present invention is that, in step S4, an identifier type 6 is defined for the domain name identifier. The identifier type 6 is used to bind website resources of the domain name system. The IP address mapped by the identifier is stored in the metadata file associated with the domain name identifier, and the username DNS_cache: i (i = 1, 2, 3, ...) is registered to realize the caching of domain name system resources.

[0055] A further improvement of the present invention is that step S5 includes the following sub-steps:

[0056] Step S501: Query the global status table. If the query is successful, proceed to step S3 for identifier resolution. If the query fails, proceed to step S502 to implement the resolution process between multiple identifier spaces and return the translation result to the user. The translation result includes the username and its identity identifier.

[0057] Step S502: Determine the identifier space to which the current identity identifier belongs based on the metadata server;

[0058] Step S503: The user requests the IPv4 address identifier from the metadata file from the metadata server;

[0059] Step S504: Routing to the storage server based on the identity identifier and IPv4 address identifier, and obtaining the associated resources of the domain name identifier.

[0060] This invention also provides a multi-identifier management and parsing system for the metaverse, which employs the multi-identifier management and parsing method for the metaverse as described above, and includes:

[0061] The formal definition module is used to define the formalities of identifiers, identifier types, identifier type sets, node sets, and identifier spaces.

[0062] The network architecture module is used to build the network architecture of the multi-identifier management and resolution system. The network layer and consensus layer are implemented through node classification and lightweight deterministic consensus algorithm, respectively. The index layer or identifier contract is implemented through hierarchical index or blockchain Solidity smart contract. The storage layer is implemented through distributed encrypted storage related to multi-identifiers.

[0063] The identifier resolution module is used to perform identifier resolution on the identifier space;

[0064] The Domain Name System (DNS) compatibility module resolves domain names using preset identifier types, enabling caching and compatibility of DNS resources.

[0065] The identifier translation module is used to perform identifier translation between multiple identifier spaces.

[0066] Compared with existing technologies, the beneficial effects of this invention are as follows: It provides a unified identifier form definition for integrating identifier types in current and future networks, constructs an identifier space that allows one or more identifier types to exist, and thus can meet the multi-identifier management and parsing needs of the metaverse. It can simultaneously manage multiple identifier types across multiple sub-metaverses, uniformly manage various identifiers in sub-metaverses, and support functions such as registration, update, revocation, and parsing, meeting the needs of the ever-evolving metaverse scenarios. Furthermore, for on-chain block data, this invention adopts a lightweight compression technology scheme, saving storage space and accelerating read and write operation speeds; for off-chain resource data, this invention adopts an encryption technology scheme based on sub-metaverse attributes, achieving privacy protection and access control.

[0067] Furthermore, this invention can migrate the index layer used to implement the core logic to Ethereum and identify contracts to implement smart contracts, thereby meeting the requirements of decentralization. Test results show that the multi-identifier management and resolution performance of this invention is significantly superior to the current Domain Name System and its upgrade / replacement technologies. Attached Figure Description

[0068] Figure 1 This is a schematic diagram of the workflow of one embodiment of the present invention;

[0069] Figure 2 This is a schematic diagram of the identifier space division according to an embodiment of the present invention;

[0070] Figure 3 This is a schematic diagram of a network architecture according to an embodiment of the present invention;

[0071] Figure 4 This is a schematic diagram of the identifier translation function according to an embodiment of the present invention;

[0072] Figure 5 This is a schematic diagram of a blockchain Solidity smart contract according to an embodiment of the present invention. Detailed Implementation

[0073] The preferred embodiments of the present invention will now be described in further detail with reference to the accompanying drawings.

[0074] Existing domain name systems and their upgrade / replacement technologies are mostly built on public blockchains. However, considering the potential for a wide range of sub-meta-universes and different types of resources in the future metaverse, these public blockchain-based domain name systems and their upgrade / replacement systems still face many challenges. Since public blockchains are permissionless, compliance checks on identifiers and security guarantees for small public blockchains are urgent issues to be addressed. Furthermore, blockchain-based domain name systems and their upgrade / replacement systems generally only have a single identifier, and there is currently a lack of mature solutions for managing and resolving multiple identifiers.

[0075] To address the aforementioned issues, this application provides a multi-identifier management and parsing method and system for the metaverse. By integrating identifier types in the current and future networks, a unified structure is designed for these identifiers, a corresponding identifier space is constructed, and a multi-identifier blockchain system that can simultaneously manage multiple sub-metaverses is proposed to meet the needs of the ever-evolving metaverse scenarios in the future.

[0076] like Figure 1 As shown, this embodiment provides a multi-identifier management and parsing method for the metaverse, including the following steps:

[0077] Step S1: Define the form of the identifier, the identifier type, the set of identifier types, the set of nodes, and the identifier space.

[0078] Step S2: Build the network architecture of the multi-identifier management and resolution system. Implement the network layer and consensus layer through node classification and lightweight deterministic consensus algorithm, respectively. Implement the index layer or identifier contract through hierarchical index or blockchain Solidity smart contract. Implement the storage layer through distributed encrypted storage related to multi-identifiers.

[0079] Step S3: Perform identifier resolution on the identifier space;

[0080] Step S4: Resolve the domain name using a preset identifier type to achieve caching and compatibility of domain name system resources;

[0081] Step S5: Perform identifier translation between multiple identifier spaces.

[0082] The main resources in current metaverse applications are identity, content, service, space, and their associated data. Just as IPv4 addresses operate at the network layer of traditional network architectures, identifiers such as identity, content, service, and space will be of great significance in future networks. Therefore, a metaverse-oriented multi-identifier management and resolution method is proposed, and a multi-identifier management and resolution system (hereinafter referred to as MIS) employing this metaverse-oriented multi-identifier management and resolution method is further provided.

[0083] In this embodiment, step S1 and the form definition module are used to define a unified form for MIS identifiers and further provide a form definition for the identifier space. Specifically, in step S1, the identifier form for a user or device is defined as i j =type j :identifier_name, defines the identifier for a user or device through a combination of two strings, where type j(j = 0, 1, 2, ..., k) represents the identifier type, such as identity, IPv4 (v6) address, content, service, geographic location, and hyperbolic coordinates; identifier_name represents the specific identifier information.

[0084] The set of identifier types is defined as I = {i0, i1, i2, ...}, where i0 represents the identity of the user or device, and the identity identifier i0 is a basic and essential identifier; {i1, i2, ...} represents various identifiers other than identity, such as content i1, service i2, geographical location i3, and IPv4 address i4, etc. k This represents a subset of I. For example, if k=2, then I2={i0, i1}.

[0085] The node set is defined as V, representing all nodes in the network, including terminal devices, hosts, routers, and switches. The identifier space is defined as a binary tuple. Among them, I k Represents the identifier space Internal identifier types, It is a subset of the node set V.

[0086] In step S1 of this embodiment, a marker space determination process is also included to determine the marker space. Whether a complete identifier space is constituted in the network includes the following sub-steps:

[0087] Step S101, using the formula Determine the identifier space If the identifier type and node within the network have already been defined, proceed to step S102; otherwise, proceed to step S102. It does not constitute a complete identifier space;

[0088] Step S102, using the formula i0∈I k Determine the identifier space If the set of identifier types contains an identity, proceed to step S103 if yes; otherwise, proceed to step S103. The set of identifier types within does not include identity;

[0089] Step S103, using the formula And i j ∈I k Determine the identifier space Does the internal node possess all the identifier types contained in the identifier space? Does v possess i? j If yes, then proceed to step S104; otherwise, then... The nodes within do not own all Included identifier types; Represents all nodes;

[0090] Step S104, using the formula if and Determine the identifier space Inside, there is a set I k Do all nodes of the identifier type belong to If yes, then determine the identifier space. This already constitutes a complete identifier space within the network. That is, if and v owns i j ,but Represents any node.

[0091] like Figure 2 The diagram illustrates how the identifier space in a network is divided. Each circle represents a node and its identifier type. The identity identifier (i0) is the basic identifier possessed by all nodes, so the entire network is the identity identifier space. Different identifier spaces can be defined by including different identifiers, including but not limited to content identifier space, IPv4 address identifier space, identity identifier space, service identifier space, and geographic location identifier space.

[0092] Step S2 and the network architecture module described in this embodiment are used to build a 4-layer architecture for the MIS, including a basic MIS and an EMIS based on smart contracts.

[0093] In the four-layer architecture of Basic MIS, Basic MIS aims to fundamentally maintain the global state of multiple identifiers and related resource data among trusted core nodes, and is therefore built on a consortium blockchain. The four-layer architecture of Basic MIS is as follows: Figure 3 As shown. In the lower two layers, candidate nodes need to compete to participate in the consensus process in order to be elected as core nodes. Core nodes run a lightweight deterministic consensus algorithm and record resource state changes in the form of transactions. Meanwhile, in the upper two layers, the metadata and complete data of the resources are hierarchically indexed, ultimately achieving off-chain distributed encrypted storage.

[0094] That is, step S2 in this embodiment includes the following sub-steps:

[0095] Step S201: The network layer is implemented through node classification. The core network consists of nodes responsible for managing unified level identifiers and processing messages at different levels.

[0096] Step S202: A consensus layer is implemented using a lightweight deterministic consensus algorithm. All blocks are divided into hot blocks, warm blocks, and cold blocks according to their height. Each node of the hot block stores the block information. Some nodes of the warm block cache the block information. The nodes of the cold block only store the block header and erasure code block generated in the warm block. When a block changes from a hot block to a warm block, each node of the warm block first encodes it into a preset number of data blocks and code blocks using erasure coding. Then, each node stores an erasure code block.

[0097] Step S203: Perform hierarchical indexing on the metadata and complete data of the resource to realize the index layer. Save the username table and multiple MIS identifier tables through key-value pairs. Each record in the username table corresponds to a MIS identifier table. The content of the record includes the binding record of multiple identifiers, the hash information of the username and identifier.

[0098] Step S204: A storage layer is implemented by storing complete off-chain resource data related to multiple identifiers. During the storage process, the data owner uses a symmetric key to encrypt the resource data through the MIS processor and encrypts the symmetric key based on the access control policy.

[0099] More specifically, in this embodiment, the first layer, namely the network layer of the block node, is implemented through step S201.

[0100] This embodiment implements the second layer, namely the lightweight consensus layer, through step S202. It employs an efficient Parallel Voting Consensus (PPoV) algorithm to write and verify relevant transactions and proposes a lightweight storage timeline strategy. In this strategy, all blocks are categorized into hot, warm, and cold blocks based on their height. The newest block is designated as a hot block by default, and the oldest block as a cold block. Since hot blocks are frequently accessed, each node in a hot block stores its information. Warm blocks, located between hot and cold blocks, have a certain probability of being accessed, so some nodes in warm blocks cache their information. Cold blocks are accessed less frequently; therefore, in this stage, nodes in cold blocks only store the block headers and erasure code blocks generated in warm blocks and do not cache them to avoid generating unnecessary cached data. When a block changes from a hot block to a warm block, each node in the warm block first uses erasure coding to encode it into a preset number of data chunks and parity chunks. Then, each node stores an erasure coding block. If an erasure coding block has an error, the node can request the erasure coding blocks of other nodes to help decode the original data block.

[0101] This embodiment uses step S203 to implement the third layer, namely the index layer, which maintains the global state of the basic MIS, including which identifier spaces possess which identifiers and how to access the off-chain resource data associated with these identifiers. The MIS processor is also responsible for handling the identifier management logic. In the MIS, a metaverse object can have multiple identifiers, which can be dynamically added, updated, or deleted as the network changes. This embodiment uses a non-relational database to store a username table and multiple MIS identifier tables through key-value pairs. A key-value pair means that a value can be obtained based on a key. This embodiment uses key-value pairs to store the username table and multiple MIS identifier tables, so that each username record corresponds to a MIS identifier table, including the binding record of multiple identifiers, the hash of the username and identifier (as the metadata address of the associated resource), and other related information.

[0102] This embodiment uses step S204 to implement the fourth layer, namely the storage layer, which is responsible for storing complete off-chain resource data related to multiple identifiers. Since resource data, such as user information tables, contains some user privacy information, this embodiment encrypts the actual resource data at this layer to protect privacy. Furthermore, this layer also designs a data storage and access scheme with multi-permission attribute-based encryption to achieve secure and controllable off-chain storage. In the technical solution of this embodiment, the data owner (DO) uses a symmetric key to encrypt resource data through the MIS processor and encrypts the key based on an access control policy.

[0103] It is worth noting that features related to the sub-universe are used as user attributes in this technical solution. In step S204, each sub-universe has an Attribute Authorization Authority (AA) responsible for user authentication and generating corresponding attribute keys to ensure that only data users who meet the corresponding policies and possess the corresponding attribute keys can decrypt resource data.

[0104] In summary, the basic four-layer architecture of the MIS exhibits good scalability and maintains loose coupling between different layers, allowing modification of a particular layer without altering the operational logic of other layers. This provides a solid foundation for the smart contract-based EMIS proposed later in this embodiment.

[0105] The basic functions of the basic MIS in this embodiment include, but are not limited to, identifier resolution implemented in step S3, DNS compatibility implemented in step S4, and identifier translation implemented in step S5.

[0106] When there is only one identifier space in the network, the basic MIS provides an identifier resolution service similar to a DNS system (i.e., a Domain Name System). When identifier resolution is successful, the user can access the storage server or related resources. More specifically, step S3 in this embodiment includes the following sub-steps:

[0107] Step S301: The user queries the global status table of the MIS to obtain the metadata address hash (Username + Identifier) ​​and the summary information of the associated resource;

[0108] Step S302: Based on the metadata address, the user accesses the metadata server and receives a metadata file, which includes, but is not limited to, the location of the storage server, access control policies, and symmetric keys.

[0109] Step S303: After receiving the metadata file, the user requests the encrypted resource data associated with the identifier from the network. This process includes both push and pull methods, both of which are integrated into the multi-identifier router (MIR). It should be noted that when using pull transmission, the user does not need the actual access storage server location recorded in the metadata file; that is, when using pull transmission, only the access control policy and symmetric key are needed.

[0110] Step S304: After the user receives the encrypted resource data associated with the identifier, the user first decrypts it using the symmetric key and performs an integrity check based on the digest information. If the check passes, the identifier is considered to have been successfully parsed; otherwise, the user returns to step S303 to continue the request.

[0111] Although the IP address identifiers in the MIS of this embodiment differ from those in the Internet, this embodiment is still compatible with traditional DNS. This is because, in step S4 of this embodiment, an identifier type 6 is defined for the domain name identifier. This identifier type 6 is used to bind website resources in the Domain Name System. That is, identifier type 6 is a special identifier type predefined for the domain name identifier. This type of identifier binds to website resources in the traditional DNS system, and its mapped IP address is stored in the metadata file associated with the domain name identifier. A username DNS_cache:i (i = 1, 2, 3, ...) is registered to implement caching of Domain Name System resources.

[0112] When a user or device wants to resolve a domain name, this embodiment first queries the MIS identifier table of the username record (DNS_cache: i). If the query fails, the MIS processor forwards the query request to the DNS server in a DNS-recognizable form, updates the domain name identifier cache in the MIS global state table, and then stores the DNS response information in the associated metadata file for the user's next query.

[0113] Considering that domain names are actually controlled by DNS servers rather than by users or devices in the basic MIS, the caching process in this embodiment does not require waiting for consensus like registration identities and other identifiers, but is directly cached to improve efficiency. That is, for DNS compatibility, this application aims to improve compatibility performance and efficiency through identifier type type6 and username DNS_cache: i (i = 1, 2, 3, ...), where the reliability of the domain name resolution service provided by the basic MIS depends on the DNS itself.

[0114] Beyond TCP / IP networks, future networks will feature many different types of identifiers (and corresponding communication patterns) to meet new functionalities or requirements. For example, content identifiers are advantageous for accessing resources such as videos and web pages. Service identifiers improve the flexibility, loose coupling, and reusability of services. Identity and location identifiers are suitable for mobile devices that are constantly changing locations.

[0115] Therefore, this embodiment encourages resource providers to apply for as many identifiers and publish resources as possible, thereby forming multiple identifier spaces in the network. Through the identifier translation service, the basic MIS can support users in resolving various identifiers and obtaining resources, as detailed in the following process... Figure 4 As shown.

[0116] like Figure 4 As shown, assume that identity space C0 supports identity identifiers (i0). In addition to the basic identity identifier (i0), identity space C1 also supports IPv4 address identifiers (i5) and domain name identifiers (i6), and identity space C2 also supports content identifiers (i1). The metadata server possesses all identifier types (i0, i1, i5, i6). Ordinary end-user E only possesses the necessary identity identifiers and therefore resides in identity space C0.

[0117] like Figure 4 As shown, this embodiment registers a special username in the MIS, such as DNS_cache:i (i = 1, 2, 3, ..., to be responsible for caching DNS resources. When a user or device wants to resolve a domain name, the preferred steps include: first, querying the MIS identifier table of the username record (DNS_cache:i). If the query fails, the MIS processor will forward the query request to the DNS server in a DNS-recognizable form, update the domain name identifier cache in the MIS global state table, and then store the DNS response information in the associated metadata file for the user's next query. The MIS processor will execute the above resolution process and return the translation result to user E, including the username (DNS_cache:1) and its identity identifier (type0: 04d9806ec30dac7e5).

[0118] More specifically, the preferred method may include the following sub-steps: Step S401, query the MIS identifier table of the username record (DNS_cache: i), such as querying identifier type6: metaverse.sub3.com, etc.; Step S402, forward the query request to the DNS server; Step S403, the DNS server responds to the query information and updates the domain name identifier cache in the global state table; Step S404, obtain the MIS identifier table corresponding to the username table through key-value pairs; Step S405, perform identifier translation through the MIS identifier table, for example, translate to DNS_cache; type0: 00000000000000000; Step S406, use the username and identifier DNS_cache; type6: metaverse.sub3.com to request metadata from the metadata server; Step S407, request the resources associated with type6: metaverse.sub3.com from the storage server; Step S408, confirm the resources associated with type6: metaverse.sub3.com. Of course, the above resolution process is one of the preferred methods, which facilitates the resolution of domain names through preset identifier types to achieve compatibility with domain name system resources. In practical applications, it can also be adjusted according to actual conditions and needs.

[0119] Step S5 in this embodiment includes the following sub-steps:

[0120] In step S501, when user E wants to resolve the domain name (type6: scholar.google.com) in identifier space C1, the global state table is queried first. If the query is successful, the process jumps to step S3 for identifier resolution. If the query fails, the process jumps to step S502 to implement the resolution process between multiple identifier spaces and return the translation result to the user. The translation result includes the username (DNS_cache: 1) and its identity identifier (type0: 04d9806ec30dac7e5). At this time, the domain name identifier (type6: scholar.google.com) has a form that can be recognized by identifier space C0.

[0121] Step S502: Determine the identifier space to which the current identity identifier belongs based on the metadata server, such as identity identifier space C0, identifier space C1, and identifier space C2, etc. The identifier space to which it belongs can be determined by the current identity identifier and the metadata server.

[0122] Step S503: User E requests the IPv4 address identifier (type5: 142.251.42.228) from the metadata file from the metadata server;

[0123] In step S504, the system routes the data to the storage server S1 based on the identity identifier (type0: 04d9806ec30dac7e5) and the IPv4 address identifier (type1: 142.251.42.228), and obtains the associated resources with the domain name identifier (type6: scholar.google.com).

[0124] Similarly, user E can also resolve the content identifier (type1: / metaverse_sub1 / 002.mp4) in identifier space C2. The difference between this process and resolving the IPv4 address identifier in identifier space C1 is that identity and IPv4 address data are obtained using a push mode, while content data is obtained using a pull mode. Therefore, this resolution process requires a change in communication mode. MIN implements a dual communication mode in the protocol stack that simultaneously supports push and pull semantics. Simply put, this embodiment can set up one or more edge routers in each identifier space to handle packets sent to other identifier spaces, including identifying identifier types and changing semantics.

[0125] In summary, the identifier translation service provided by the basic MIS implemented in this embodiment enables the same resource data to exist in multiple forms / identifiers and to be accessed by users in different identifier spaces of the sub-universe.

[0126] The basic MIS described above is built on a consortium blockchain. However, due to Ethereum's outstanding characteristics in decentralization and programmability, most metaverse projects are actually built upon it. Therefore, this embodiment further modifies the loosely coupled four-layer architecture of the basic MIS and proposes an Ethereum version of the MIS, namely EMIS.

[0127] The bottom two layers of EMIS follow Ethereum's native design, including node classification and Proof-of-Stake (PoS) consensus. The top layer uses the basic MIS storage layer. Specifically, since the intermediate index layer is responsible for the core logic related to identity management, this embodiment redesigns this layer in EMIS using Solidity smart contracts, primarily consisting of the EMIS contract and the identity contract, as follows... Figure 5 As shown.

[0128] More specifically, unlike the basic MISA, step S2 in this embodiment includes the following sub-steps:

[0129] Step S201: The network layer is implemented through node classification. The core network consists of nodes responsible for managing unified level identifiers and processing messages at different levels.

[0130] Step S202: A consensus layer is achieved through Proof-of-Stake (PoS) consensus.

[0131] Step S203' involves implementing identification contracts through the Solidity smart contract on the blockchain. Resources are associated with identifications to form identification contracts corresponding to resource types. These identification contracts include identity identification contracts, content identification contracts, and service identification contracts, each maintaining a corresponding identification table. During identification resolution, the EMIS contract first selects the appropriate identification contract based on the identification type. Then, the identification contract retrieves resource information from the identification table based on the actual identification, and finally checks its attributes and accesses the metadata and resource data associated with the identification. It should be noted that the original plaintext of the resource data is only available to users whose attributes match.

[0132] Step S204: Implement the storage layer by storing complete off-chain resource data related to multiple identifiers.

[0133] Similar to basic MIS contracts that use public keys as identity identifiers, the identity identifier of an EMIS contract is uniquely bound to a user's Ethereum address. However, since Ethereum addresses are difficult to remember, this invention uses usernames to simplify identity identification. Specifically, the EMIS contract maintains a username table and supports username registration, updating, revocation, transfer, and authorization. Furthermore, interfaces from multiple identity contracts are integrated into the EMIS identity contract for unified invocation.

[0134] This embodiment predefines that users of the identification service must have a username. After a user submits relevant information to the EMIS contract, the registration process is completed once the block is confirmed. Registered users need to associate their username with their sub-metaverse attributes to access specific resource data. The username owner has the right to update and revoke the username at any time, or choose to transfer it to another user, meaning that ownership will completely change. Furthermore, a major functional extension of EMIS compared to basic MIS is the support for users to delegate the management of their usernames to a third party. Through the EMIS contract, users can terminate the delegation and reauthorize it for new users at any time.

[0135] Another functional extension of EMIS is preventing registration squatting. Considering that a public blockchain is an open network, even normally functioning nodes may be driven by profit to parse and construct identical registration transactions before the relevant transactions are submitted to the chain, and then preemptively register by increasing gas fees. In this way, nodes can easily complete registration squatting without paying for username processing. Therefore, this embodiment adopts a two-phase "request-submit" registration model as a means to alleviate the registration squatting problem. In the first phase, the username is not directly submitted; instead, the username, user address, and secret value (random number) are hashed off-chain. At this stage, the transaction only records the hashed value and does not reveal the original information. The second phase transaction records the actual username to be registered and the secret value. The contract re-hashes and calculates a new value based on these two values ​​and the address of the transaction signer, and checks if it is equal to the value submitted in the first phase. Only users whose values ​​match can register their usernames.

[0136] In EMIS, resources are uniquely associated with identifiers. To manage and resolve different types of identifiers, this embodiment has developed corresponding contracts for each type of identifier, such as identity identifier contracts, content identifier contracts, and service identifier contracts, collectively referred to as identifier contracts. Each identifier contract maintains an identifier table and provides functions such as identifier registration, update, revocation, transfer, and resolution.

[0137] When a user wants to publish a resource, they must register the corresponding type of identifier. Identifiers can be generated automatically or manually. After submitting resource information, the user needs to pay for the associated identifier, which consists of two parts: a transaction fee and a gas fee. The former is used to calculate the identifier's validity period, and the latter is used to execute the identifier contract.

[0138] Similar to a basic MIS, an identifier can be updated or revoked within its validity period. Therefore, users cannot modify expired identifiers. However, users can extend the validity period of their active identifiers through the update service. It is important to note that only the owner or authorized user can perform these operations on the identifier.

[0139] This embodiment also provides a multi-identifier management and resolution system for the metaverse, which adopts the multi-identifier management and resolution method for the metaverse as described above, and includes:

[0140] The formal definition module is used to define the formalities of identifiers, identifier types, identifier type sets, node sets, and identifier spaces.

[0141] The network architecture module is used to build the network architecture of the multi-identifier management and resolution system. The network layer and consensus layer are implemented through node classification and lightweight deterministic consensus algorithm, respectively. The index layer or identifier contract is implemented through hierarchical index or blockchain Solidity smart contract. The storage layer is implemented through distributed encrypted storage related to multi-identifiers.

[0142] The identifier resolution module is used to perform identifier resolution on the identifier space;

[0143] The Domain Name System (DNS) compatibility module resolves domain names using preset identifier types, enabling caching and compatibility of DNS resources.

[0144] The identifier translation module is used to perform identifier translation between multiple identifier spaces.

[0145] Therefore, this embodiment provides a unified identifier form definition for integrating identifier types in the current and future networks, constructing an identifier space that allows one or more identifier types to exist. This satisfies the multi-identifier management and parsing requirements of the metaverse, enabling the simultaneous management of multiple identifier types across multiple sub-metaverses, unified management of various identifiers within sub-metaverses, and support for functions such as registration, update, revocation, and parsing, thus meeting the needs of the ever-evolving metaverse scenarios. Furthermore, for on-chain block data, this invention employs a lightweight compression technology, saving storage space and accelerating read / write operations; for off-chain resource data, this invention uses an encryption technology based on sub-metaverse attributes, achieving privacy protection and access control.

[0146] Furthermore, this embodiment can migrate the index layer used to implement the core logic to Ethereum and identify contracts to implement smart contracts, thereby meeting the requirements of decentralization. Test results show that the multi-identifier management and resolution performance of this invention is significantly superior to the current domain name system and its upgrade / replacement technologies.

[0147] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A multi-identifier management and parsing method for the metaverse, characterized in that, Includes the following steps: Step S1: Define the form of the identifier, the identifier type, the set of identifier types, the set of nodes, and the identifier space. Step S2: Build the network architecture of the multi-identifier management and resolution system. Implement the network layer and consensus layer respectively through node classification and lightweight deterministic consensus algorithm. Implement the index layer through hierarchical index or implement the identifier contract through blockchain Solidity smart contract. Implement the storage layer through distributed encrypted storage related to multi-identifiers. Step S3: Perform identifier resolution on the identifier space; Step S4: Resolve the domain name using a preset identifier type to achieve caching and compatibility of domain name system resources; Step S5: Perform identifier translation between multiple identifier spaces; In step S2, the process of implementing the index layer through hierarchical indexing is as follows: hierarchical indexing is performed on the metadata and complete data of the resource to implement the index layer. Username table and multiple MIS identifier tables are stored through key-value pairs. Each record in the username table corresponds to a MIS identifier table. The content of the record includes binding records of multiple identifiers, hash information of username and identifier. In step S2, the process of implementing the identifier contract through the Solidity blockchain smart contract is as follows: the identifier contract is implemented through the Solidity blockchain smart contract, and resources are associated with identifiers one by one to form an identifier contract corresponding to the resource type. The identifier contract includes identity identifier contract, content identifier contract and service identifier contract. Each identifier contract maintains a corresponding identifier table. In the identifier resolution process, the corresponding identifier contract is first selected according to the identifier type. Then, the identifier contract obtains resource information from the identifier table according to the actual identifier. Finally, its attributes are checked and the metadata and resource data associated with the identifier are accessed. In step S4, an identifier type is defined for the domain name identifier. The identifier type Website resources used to bind to the Domain Name System (DNS) have their mapped IP addresses stored in a metadata file associated with the domain name identifier, and usernames are registered. To implement caching of Domain Name System resources, among which, It is a positive integer.

2. The multi-identifier management and parsing method for the metaverse according to claim 1, characterized in that, In step S1, the identifier of the user or device is defined as follows: ,in, This indicates the identifier type. ; This represents identification information; the identification type set is defined as follows: ,in This indicates the identity of the user or device. It represents multiple identifiers beyond identity. It means A subset; a node set is defined as The identifier space is defined as a binary tuple. , ,in, Represents the identifier space Internal identifier types, It is a set of nodes A subset of.

3. The multi-identifier management and parsing method for the metaverse according to claim 2, characterized in that, Step S1 also includes an identifier space determination process for determining the identifier space. Whether a complete identifier space is constituted in the network includes the following sub-steps: Step S101, using the formula Determine the identifier space If the identifier type and node within the network have already been defined, proceed to step S102. Step S102, using the formula Determine the identifier space If the set of identifier types contains an identity, proceed to step S103. Step S103, using the formula and Determine the identifier space If the internal node possesses all the identifier types contained in the identifier space, then proceed to step S104. Step S104, using the formula and Determine the identifier space Inside, there is a collection Do all nodes of the identifier type belong to Until then, determine the identifier space. It has already formed a complete identifier space in the network.

4. The multi-identifier management and parsing method for the metaverse according to any one of claims 1 to 3, characterized in that, Step S2 includes the following sub-steps: Step S201: The network layer is implemented through node classification. The core network consists of nodes responsible for managing unified level identifiers and processing messages at different levels. Step S202: A consensus layer is implemented using a lightweight deterministic consensus algorithm. All blocks are divided into hot blocks, warm blocks, and cold blocks according to their height. Each node of the hot block stores the block information, some nodes of the warm block cache the block information, and the nodes of the cold block only store the block header and erasure code block generated in the warm block. When a block changes from a hot block to a warm block, each node of the warm block first encodes it into a preset number of data blocks and code blocks using erasure coding, and then stores an erasure code block in each node. Step S203: A storage layer is implemented by storing complete off-chain resource data related to multiple identifiers. During the storage process, the data owner uses a symmetric key to encrypt the resource data through the MIS processor and encrypts the symmetric key based on the access control policy.

5. The multi-identifier management and parsing method for the metaverse according to claim 4, characterized in that, Each sub-universe corresponds to an attribute authorization authority, which is responsible for user authentication and generating the corresponding attribute keys.

6. The method for managing and resolving multiple identifiers for the metaverse according to any one of claims 1 to 3, characterized in that, Step S2 includes the following sub-steps: Step S201: The network layer is implemented through node classification. The core network consists of nodes responsible for managing unified level identifiers and processing messages at different levels. Step S202: A consensus layer is achieved through proof-of-stake consensus. Step S203: Implement the storage layer by storing complete off-chain resource data related to multiple identifiers.

7. The method for managing and resolving multiple identifiers for the metaverse according to any one of claims 1 to 3, characterized in that, Step S3 includes the following sub-steps: Step S301: Query the global status table to obtain the metadata address. And summary information of the associated resources; Step S302: Access the metadata server according to the metadata address and receive a metadata file, the metadata file containing the location of the storage server, access control policy and symmetric key; Step S303: After the user receives the metadata file, he requests the encrypted resource data associated with the identifier from the network. Step S304: After the user receives the encrypted resource data associated with the identifier, the user first decrypts it using the symmetric key and performs an integrity check based on the digest information. If the check passes, the identifier is considered to have been successfully parsed; otherwise, the user returns to step S303 to continue the request.

8. The multi-identifier management and parsing method for the metaverse according to any one of claims 1 to 3, characterized in that, Step S5 includes the following sub-steps: Step S501: Query the global status table. If the query is successful, proceed to step S3 for identifier resolution. If the query fails, proceed to step S502 to implement the resolution process between multiple identifier spaces and return the translation result to the user. The translation result includes the username and its identity identifier. Step S502: Determine the identifier space to which the current identity identifier belongs based on the metadata server; Step S503: The user requests the IPv4 address identifier from the metadata file from the metadata server; Step S504: Routing to the storage server based on the identity identifier and IPv4 address identifier, and obtaining the associated resources of the domain name identifier.

9. A multi-identifier management and resolution system for the metaverse, characterized in that, The method for managing and resolving multiple identifiers oriented towards the metaverse, as described in any one of claims 1 to 8, is adopted and includes: The formal definition module is used to define the formalities of identifiers, identifier types, identifier type sets, node sets, and identifier spaces. The network architecture module is used to build the network architecture of the multi-identifier management and resolution system. The network layer and consensus layer are implemented by node classification and lightweight deterministic consensus algorithm, respectively. The index layer is implemented by hierarchical index or the identifier contract is implemented by blockchain Solidity smart contract. The storage layer is implemented by distributed encrypted storage related to multi-identifiers. The identifier resolution module is used to perform identifier resolution on the identifier space; The Domain Name System (DNS) compatibility module resolves domain names using preset identifier types, enabling caching and compatibility of DNS resources. The identifier translation module is used to perform identifier translation between multiple identifier spaces.

Images