Architecture (Decentralization)
Vision
The vision for the Multiverse Name Service is to have a fully decentralized blockchain architecture. This means that the service would continue to be usable on the blockchain even if other portions are down such as the web front end. Furthermore, it gives security for its users that no one can tamper with their tokens.
Centralized Implementation
Enjin Blockchain has not yet shipped smart contracts which are necessary for a fully decentralized implementation. To work around this, the Multiverse Name Service will ship initially with a partially centralized implementation. Once the proper feature set is ready, it will transition to a fully decentralized smart contract.
The portions that are currently decentralized for the service...
Tokens which represent names are fully on chain.
Developers make on chain calls to validate if a wallet has ownership of a name.
Portions of the service which are currently centralized...
registering a name token is done through a centralized web service.
The mapping of names that have already been registered is stored in an off-chain database.
All tokens are minted through a single master wallet which owns the collection.
Architecture Diagram
Decentralized Implementation
Once Enjin Blockchain has shipped smart contract support as well as wallet connect, Multiverse Name Service will transition to a fully decentralized implementation. The centralized logic will be migrated into an on-chain smart contract which will be open sourced. The web service will then become a thin front end for invoking the smart contract, but users will be able to invoke the smart contract directly if they prefer.
Architecture Diagram
Migration Plan
Because the service will start out centralized, it will be necessary to migrate the existing metadata into the smart contract. In order to achieve this, the smart contract API will expose API's to register existing name tokens into it. This API will give the owner of the contract the minimum necessary capabilities to do the migration. The migration process will be like the following...
Stop all new registrations on the centralized service.
Deploy the smart contract with a starting token id higher than the highest one used by the centralized service.
Use the bootstrap API to write the existing tokens into the smart contract one at a time.
Redeploy the web service to use the smart contract service instead of the centralized service.
Enabled new registrations again.
Last updated