CN114707973A - Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application - Google Patents

Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application Download PDF

Info

Publication number
CN114707973A
CN114707973A CN202210226827.9A CN202210226827A CN114707973A CN 114707973 A CN114707973 A CN 114707973A CN 202210226827 A CN202210226827 A CN 202210226827A CN 114707973 A CN114707973 A CN 114707973A
Authority
CN
China
Prior art keywords
digital
digital asset
address
uint256
assets
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210226827.9A
Other languages
Chinese (zh)
Inventor
焦臻桢
田锐
尚德重
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhongke Wuyuan Hangzhou Computing Technology Co ltd
Zhongke Computing Technology Innovation Research Institute
Original Assignee
Zhongke Wuyuan Hangzhou Computing Technology Co ltd
Zhongke Computing Technology Innovation Research Institute
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhongke Wuyuan Hangzhou Computing Technology Co ltd, Zhongke Computing Technology Innovation Research Institute filed Critical Zhongke Wuyuan Hangzhou Computing Technology Co ltd
Priority to CN202210226827.9A priority Critical patent/CN114707973A/en
Publication of CN114707973A publication Critical patent/CN114707973A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123—Shopping for digital content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Abstract

The invention relates to a chain uplink and downlink coordinated digital asset management method and protocol for metastic application. The technical scheme adopted by the invention is as follows: a method for managing uplink and downlink collaborative digital assets of a chain facing meta-universe application comprises the following steps: the management tool calls a download interface function of the corresponding digital asset to the corresponding block chain according to the ID of the digital asset to be downloaded; after the download interface function of the digital assets on the blockchain is called, the transaction and transfer interface function corresponding to the digital assets is set to be non-callable, and meanwhile, the blockchain feeds back all digital contents corresponding to the digital assets to a management tool; the management tool packs all the digital contents into a chain download file and finishes the encryption operation of the private key; after the chain download file is packaged, the management tool obtains partial authority of the corresponding digital asset, and the partial authority is used for changing and calling the state of the digital asset on the block chain originally bearing the digital asset when the management tool uploads the digital asset.

Description

Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application
Technical Field
The invention relates to a chain uplink and downlink coordinated digital asset management method and protocol for metastic application. The method is suitable for the technical field of block chains.
Background
The blockchain is considered as a support platform for the digital assets in the metasphere, completes the functions of issuing, managing and the like of the digital assets in the metasphere, and supports the economic system of the metasphere. Due to the decentralized and Non-tamper-proof characteristics of the block chain technology, the block chain technology can provide ownership proof of Non-homogeneous Tokens (NFT) as a credential type for digital assets, and stores and distributes the digital assets in a distributed mode and the like, and meanwhile, the uniqueness of the digital assets is ensured and the digital assets are not tamper-proof. Due to this characteristic, NFT is widely applied in the fields of digital assets and the like, and will be widely applied in meta-space scenes.
The Ethereum Request for Comment-721(ERC721) standard describes a non-interchangeable corroboration, and most NFT generation methods are based on the ERC721 standard. However, the current protocols such as ERC721 still have more limitations, so that the application scenario is still single. The method cannot meet the requirement of generating and managing digital assets in a large number and in multiple types in the meta-space scene. Secondly, in the initial stage of the metasma, digital asset management inevitably needs to face the problem of interconnection and intercommunication of digital assets among multiple chains and multiple platforms, so the problem of coordination of digital assets on and off the chains must be solved, which is also missing in the conventional ERC protocol at present.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: aiming at the existing problems, a method and a protocol for managing the uplink and downlink collaborative digital assets of the chain facing the metauniverse application are provided.
The technical scheme adopted by the invention is as follows: a chain uplink and downlink collaborative digital asset management method oriented to metauniverse application is used for downloading digital assets from a chain, and is characterized in that:
the management tool calls a downloading interface function of the corresponding digital asset under the corresponding account of the downloading user to the corresponding block chain according to the ID of the digital asset to be downloaded provided by the downloading user and the block chain identification bearing the digital asset;
after the download interface function of the digital assets on the blockchain is called, the transaction and transfer interface function corresponding to the digital assets is set to be non-callable, and meanwhile, the blockchain feeds back all digital contents corresponding to the digital assets to a management tool;
after the management tool acquires the digital content, packaging all the digital content into a chain download file, and finishing private key encryption operation based on an encryption key provided by a download user;
after the chain download file is packaged, the management tool obtains partial authority of the corresponding digital asset, and the partial authority is used for changing and calling the state of the digital asset on the block chain originally bearing the digital asset when the management tool uploads the digital asset.
A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is an original block chain bearing the digital assets, the method is characterized in that:
the management tool completes decoding according to a chain download carrier file and an encryption key provided by an uploading user, wherein the chain download carrier file is generated when the digital assets are downloaded from the chain according to the chain uplink and downlink collaborative digital asset management method for the meta-space application;
after decoding is successful, the management tool calls an uploading interface function of the digital asset on the block chain, and then the transaction and transfer interface function corresponding to the digital asset is set to be callable from a non-callable state;
and the management tool calls a transaction and transfer interface function corresponding to the digital asset on the block chain, and transfers the digital asset from the original owner account to the account corresponding to the uploading user through the transaction and transfer interface function.
A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is a block chain which originally bears the digital assets, the method is characterized in that:
the management tool completes decoding according to a chain download carrier file and an encryption key provided by an uploading user, wherein the chain download carrier file is generated when the digital assets are downloaded from the chain according to the chain uplink and downlink collaborative digital asset management method for the meta-space application;
after decoding is successful, corresponding digital assets are created on a target block chain based on digital contents of the digital assets, then transaction and transfer interface functions corresponding to the digital assets are set to be invokable on the target block chain, and owners of the digital assets are changed into accounts corresponding to uploading users;
after the digital assets on the target block chain are successfully created, a signaling is sent to a management tool, the management tool calls a function of destroying the existing digital asset interface of the corresponding digital assets on the original block chain after receiving the signaling, and the digital assets on the original block chain are discarded by destroying the existing digital asset interface function.
A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is a block chain which originally bears the digital assets, the method is characterized in that:
the management tool completes decoding according to a chain download carrier file and an encryption key provided by an uploading user, wherein the chain download carrier file is generated when the digital assets are downloaded from the chain according to the chain uplink and downlink collaborative digital asset management method for the meta-space application;
after decoding is successful, creating an NFT asset on a target block chain, and copying a data file in a chain download file into the NFT;
setting a transaction and transfer interface function corresponding to the NFT asset as callable on a target block chain, and changing an owner of the digital asset into an account corresponding to an uploading user;
after the NFT assets on the target block chain are successfully created, a signaling is sent to a management tool, the management tool calls a destroyed existing digital asset interface function of the corresponding digital assets on the original block chain after receiving the signaling, and the digital assets on the original block chain are abandoned through the destroyed existing digital asset interface function.
A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is a block chain which originally bears the digital assets, the method is characterized in that:
creating an NFT asset on a target block chain, taking a chain download file corresponding to the digital asset as a digital content file corresponding to the NFT, and storing the digital content file in a distributed storage system;
wherein the downlink carrier file is generated when the digital assets are downloaded from the chain according to the method for managing the downlink and uplink collaborative digital assets facing the metauniverse application.
A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is a block chain which originally bears the digital assets, the method is characterized in that:
creating a new digital asset on the target block chain, taking a chain download file corresponding to the digital asset as a digital content file corresponding to the new digital asset, and storing the digital content file in a distributed storage system;
wherein the downlink carrier file is generated when the digital assets are downloaded from the chain according to the method for managing the downlink and uplink collaborative digital assets facing the metauniverse application.
A digital asset management protocol, characterized by: the protocol defines a download interface function and a transaction and transfer interface function in the above-mentioned method for managing the chain uplink and downlink collaborative digital assets oriented to the meta-space application, and an upload interface function, a transaction and transfer interface function and a function for destroying the existing interface function of the digital assets oriented to the meta-space application.
The protocol is defined as the following interface functions:
(1) single piece digital asset transfer:
transferSingle(address_operator,address_from,address_to,uint256_tokenId,uint256_value,boolean_available)
wherein, the _ from and the _ to are respectively an exit and an entry of the digital asset, the _ token Id is the transferred digital asset id, and the uint256_ value is the number of the transferred digital assets; when the _ available is false, the function is not invokable;
(2) safe transfer of a single piece of digital assets:
safeTransferFrom(address_from,address_to,uint256_id,uint256_value,bytes calldata_data,boolean_available)
wherein _ from is a transfer-out account of the digital assets, ownership of the digital assets must be possessed, _ to is a transfer-in account of the digital assets, _ tokenId is a transferred digital asset id, _ uin 256_ value is the number of the transferred digital assets, and _ data is other text information transferred to a receiving account callback function; when the _ available is false, the function is not invokable;
(3) digital asset packaging transfer:
transferBatch(address_operator,address_from,address_to,uint256[]_ids,uint256[]_values,boolean_available)
the authorized account of the digital assets of the operator, from and to are the transferring party and the transferring party of the digital assets respectively, ids is a list of the id of the digital assets to be transferred, and values is the number of each digital asset in the list of the digital assets to be transferred; when the _ available is false, the function is not invokable;
(4) packaging and safely transferring the digital assets:
safeBatchTransferFrom(address_from,address_to,uint256[]calldata_ids,uint256[]calldata_values,bytes calldata_data,boolean_available)
wherein, the 'from' is an export account of the digital assets, ownership of the digital assets is required to be possessed, the 'to' is an import account of the digital assets, the 'ids' is a list of digital assets to be transferred, the 'values' is the number of each digital asset in the list of digital assets to be transferred, and the 'data' is other text information transferred to a call-back function of a receiving account; when the _ available is false, the function is not invokable;
(5) sub-digital asset transfer
transferChild(int256_fromTokenId,address_to,address_childContract,uint256_childTokenId,boolean_available)
Wherein _ fromTokenId is the parent digital asset id of the digital asset to be transferred, _ to is the transfer-in account of the digital asset, _ childcontinuously is the contract address of the digital asset, and _childtokenidis the id of the digital asset; when the _ available is false, the function is not invokable;
(6) transferring sub-digital assets to specific digital assets
transferChildToParent(uint256_fromTokenId,address_toContract,uint256_toTokenId,address_childContract,uint256_childTokenId,bytes_data,boolean_available)
Wherein fromTokenId is an upper parent digital asset to be received, toconteract is a contract address of the upper parent digital asset to be received, tototokenid is an id of the upper parent digital asset to be received, childContract is a contract address of the digital asset to be transferred, and childTokenId is an id of the digital asset; if available is false, the function is not callable.
(7) Sub-digital asset reception
receiveChild(int256 indexed_from,address_toTokenId,address_childContract,uint256_childTokenId)
Wherein _ from is an original owning account of the digital asset to be received, _ toTokenId is a parent digital asset of the digital asset to be received, _ childContract is a contract address of the digital asset, and _ childTokenId is an id of the digital asset;
(8) returning root digital assets to which a particular digital asset id belongs
rootOwnerOf(uint256_tokenId)
Wherein _tokenIdis id of the digital asset;
(9) returning root digital assets attributed to a particular digital asset
rootOwnerOfChild(address_childContract,uint256_childTokenId)
Wherein _ childContract is the contract address of the digital asset and _ childTokenId is the id of the digital asset;
(10) parent digital asset returning digital asset
ownerOfChild(address_childContract,uint256_childTokenId)
Where _ childContract is the contract address of the digital asset and _ childTokenId is the id of the digital asset.
(11) Returning the total number of the subordinate digital assets of the specific digital asset id:
totalChildContracts(uint256_tokenId)；
(12) returning corresponding digital asset contract address through digital asset id and digital asset sequence number
childContractByIndex(uint256_tokenId,uint256_index)
Wherein _ index is the serial number of the digital asset;
(13) returning id of digital asset
childTokenByIndex(uint256_tokenId,address_childContract,uint256_index)
(14) Transferring FT-type digital assets
TransferFT(uint256_fromTokenId,address_to,address_FTContract,uint256_value)
Wherein _ fromTokenId is the roll-out account of the FT digital assets, _ to is the parent digital asset to which the received FT digital assets belongs, _ ftcontrast is the FT digital asset contract to be transferred, and _valueis the number of transferred FT digital assets;
(15) viewing FT digital asset balances
balanceOfFT(uint256_tokenId,address_FTContract)
The interface checks the balance of the FT digital assets owned by the digital assets corresponding to the _ token Id, and the _ FTContract is a corresponding FT digital asset contract;
(16) receiving FT digital assets
tokenFallback(address_from,uint256_value,bytes_data)
Wherein _ from is the original account of the FT digital assets, _ value is the number of FT digital assets transferred, _ data is the parent digital asset id header field that receives the digital assets;
(17) returning a contract address for a digital asset holding a particular FT digital asset
FTContractByIndex(uint256_tokenId,uint256_index)
Wherein, the _ token Id is the digital asset id with query, and the _ value is the FT digital asset serial number held by the digital asset;
(18) producing new digital assets
mint(address_to,uint256_tokenId)
Wherein _ to is the owner of the digital asset and _ tokenId is the id of the newly produced digital asset;
(19) removing digital assets owned by a particular account from the account
_removeMUToken(address_from,uint256_tokenId)
Wherein _ from is an ownership account of the digital asset to be removed, and _ tokenId is a digital asset id to be removed;
(20) destroying existing digital assets
burn(uint256_tokenId)
Wherein the _ token Id is a digital asset id to be destroyed;
(21) paying royalty
RecievedRoyalties(address creator,address buyer,uint256 amount)
Wherein creator is the account of the creator of the digital assets, layer is the current purchaser of the digital assets, and amount is the royalty proportion paid to the creator by the purchaser;
(22) copyright tax transaction recording certificate
royaltiesRecieved(address_creator,address_buyer,uint256_amount)
Wherein creator is the account of the creator of the digital assets, layer is the current purchaser of the digital assets, and amount is the royalty proportion paid to the creator by the purchaser;
(23) checking whether digital asset contracts support royalty payments
hasRoyalties(uint256_tokenId)
Whether the digital assets corresponding to the _ tokenId have royalties or not can be checked by calling the interface;
(24) viewing specific information of digital assets containing royalties
function royaltyInfo(uint256_tokenId)
The interface returns the royalty proportion and the payment object contained in the digital asset corresponding to the _ token Id;
(25) authorization of an account for operation of a digital asset:
approve(address_to,uint256_tokenId)
wherein _ to is an authorized account, and _ token Id is an id corresponding to the digital asset;
(26) granting the account operating rights to all digital assets:
setApprovalForAll(address_operator,bool_approved)
wherein, the _ operator is an account address, when the _ approved is true, the _ operator is authorized to have all digital asset permissions, and when the _ approved is false, all digital asset permissions of the _ operator are cancelled;
(27) and inquiring the authorization condition:
isApprovedForAll(address_owner,address_operator)
wherein, the _ owner is the account address of the digital asset owner, the _ operator is the account address, if the _ operator is authorized by the _ owner, the value is returned, otherwise, the value is returned;
(28) number of digital assets held in the return account:
balanceOf(address_owner,uint256_id)
wherein _owneris an account address and _idis a digital asset id to be queried;
(29) batch return account holds digital asset types and quantities:
function balanceOfBatch(address[]calldata_owners,uint256[]calldata_ids)
wherein, owners is a group of account lists, ids is a digital asset id list to be inquired;
(30) returning the name of the digital asset:
name()
(31) returning the abbreviated name of the digital asset:
symbol()
(32) returning the name of the digital asset pointing to the digital content:
getDigitalAssetName(uint256_tokenId)
(33) returning a description of the digital asset pointing to the digital content:
getDigitalAssetDescription(uint256_tokenId)
(34) link _ url of digital content of query digital asset:
getDigitalAsset(uint256_tokenId)
the interface returns an external URL, the URL corresponds to a digital asset metadata JSON file after domain name resolution and identification, and the JSON format is as follows:
Figure BDA0003535919570000101
to support the down-link coordination, the interfaces that need to be implemented include:
(35) downloading:
crosschain_download(uint256_tokenId)
wherein _tokenIdis the digital asset id to be queried; calling the function can automatically identify the transfer authority identification bit _ available corresponding to the digital asset as 'false';
(36) uploading:
crosschain_upload(_tokenId)
wherein _tokenIdis the id of the originally downloaded digital asset; after the function is called, the asset interest transfer functions such as transferSingle and the like are called, and meanwhile, the transfer authority identification bit _ available corresponding to the digital asset is identified as 'true'.
The invention has the beneficial effects that: after the download interface function of the digital assets on the block chain is called, the corresponding transaction and transfer interface function is set to be non-callable, so that the digital assets on the chain can not be transferred after the digital assets are downloaded off line, and the digital assets can only be transferred after the corresponding digital assets are uploaded to the block chain by the management tool, thereby ensuring the ownership relationship of the digital assets on the chain and the digital assets off the chain to be consistent, and realizing the chain, chain and down cooperation of the digital assets.
When the digital assets are downloaded, all digital contents corresponding to the digital assets are packaged into a chain download body file, and the private key encryption operation is completed based on an encryption key provided by a download user; when the digital assets are uploaded and the owners are changed, the chain download files corresponding to the digital assets and the corresponding encryption keys need to be provided, so that the safety and the credibility of the assets are ensured.
Drawings
Fig. 1 is a schematic diagram of a system architecture according to an embodiment.
Detailed Description
The embodiment provides a block chain system-based future meta-space scene application-oriented Digital Asset Management protocol map (metal Digital Asset Management protocol), which can support various novel Management modes while realizing Management of Digital assets such as NFT-type non-homogeneous tokens and the like, compared with the existing ERC protocol stack, thereby enabling Management of various Digital assets to be more convenient; secondly, digital assets MUT (Metavides uniquesly identified token) on the MAP protocol standard distribution chain can be downloaded to the chain for management and circulation, and meanwhile, the asset safety and the credible identification can be ensured; furthermore, during download, the MUT may be fully compatible with and circulated over a blockchain supporting ERC-721, etc. NFT assets, enabling chain-uplink-downlink collaboration of digital assets.
In this embodiment, the MAP protocol standard defines the following interface functions:
the protocol supports single piece transfer and batch transfer of digital assets, and the related transfer interface functions are as follows:
(1) single piece digital asset transfer:
transferSingle(address_operator,address_from,address_to,uint256_tokenId,uint256_value,boolean_available)
wherein, the authorized account of the _ operator digital asset, from and to are respectively the transferring party and the transferring party of the digital asset, the tokenId is the transferred digital asset id, and the ount 256_ value is the number of the transferred digital asset; when _ available is false, the function is not callable.
(2) Safe transfer of a single piece of digital assets:
safeTransferFrom(address_from,address_to,uint256_id,uint256_value,bytes calldata_data,boolean_available)
wherein _ from is a transfer-out account of the digital assets, ownership of the digital assets must be possessed, _ to is a transfer-in account of the digital assets, _ tokenId is a transferred digital asset id, _ uin 256_ value is the number of the transferred digital assets, and _ data is other text information transferred to a receiving account callback function; when _ available is false, the function is not callable.
(3) Digital asset packaging transfer:
transferBatch(address_operator,address_from,address_to,uint256[]_ids,uint256[]_values,boolean_available)
the authorized account of the digital assets of the operator, from and to are the transferring party and the transferring party of the digital assets respectively, ids is a list of the id of the digital assets to be transferred, and values is the number of each digital asset in the list of the digital assets to be transferred; if available is false, the function is not callable.
(4) Packaging and safely transferring the digital assets:
safeBatchTransferFrom(address_from,address_to,uint256[]calldata_ids,uint256[]calldata_values,bytes calldata_data,boolean_available)
wherein, the 'from' is the transfer-out account of the digital assets, the ownership of the digital assets must be possessed, the 'to' is the transfer-in account of the digital assets, the 'ids' is the list of the digital assets id to be transferred, the 'values' is the number of each digital asset in the list of the digital assets to be transferred, and the 'data' is other literal information transferred to the call-back function of the receiving account; if available is false, the function is not callable.
The protocol supports multi-level digital asset management, the hierarchical attribution relationship of the digital assets is represented by a tree structure, except a root digital asset, any digital asset is attributed to a unique parent digital asset at the upper level, and the related digital asset management and transfer interface function comprises the following steps:
(5) sub-digital asset transfer
transferChild(int256_fromTokenId,address_to,address_childContract,uint256_childTokenId,boolean_available)
Wherein _ fromTokenId is the parent digital asset id of the digital asset to be transferred, _ to is the transfer-in account of the digital asset, _ childcontinuously is the contract address of the digital asset, and _childtokenidis the id of the digital asset; if available is false, the function is not callable.
(6) Transferring sub-digital assets to specific digital assets
transferChildToParent(uint256_fromTokenId,address_toContract,uint256_toTokenId,address_childContract,uint256_childTokenId,bytes_data,boolean_available)
Wherein fromTokenId is an upper parent digital asset to be received, toconteract is a contract address of the upper parent digital asset to be received, tototokenid is an id of the upper parent digital asset to be received, childContract is a contract address of the digital asset to be transferred, and childTokenId is an id of the digital asset; if available is false, the function is not callable.
(7) Sub-digital asset reception
receiveChild(int256 indexed_from,address_toTokenId,address_childContract,uint256_childTokenId)
Where _ from is the originally owned account of the digital asset to be received, _ toTokenId is the parent digital asset from which the digital asset was received, _ childcontinuously is the contract address of the digital asset, and _ childTokenId is the id of the digital asset.
(8) Returning root digital assets to which a particular digital asset id belongs
rootOwnerOf(uint256_tokenId)
Where _tokenidis the id of the digital asset.
(9) Returning root digital assets attributed to a particular digital asset
rootOwnerOfChild(address_childContract,uint256_childTokenId)
Where _ childContract is the contract address of the digital asset and _ childTokenId is the id of the digital asset.
(10) Parent digital asset returning digital asset
ownerOfChild(address_childContract,uint256_childTokenId)
Where _ childContract is the contract address of the digital asset and _ childTokenId is the id of the digital asset.
(11) Returning the total number of the subordinate digital assets of the specific digital asset id:
totalChildContracts(uint256_tokenId)
(12) returning corresponding digital asset contract address through digital asset id and digital asset sequence number
childContractByIndex(uint256_tokenId,uint256_index)
Where _ index is the serial number of the digital asset.
(13) Returning id of digital asset
childTokenByIndex(uint256_tokenId,address_childContract,uint256_index)
The hierarchical digital asset should also be able to take FT (functional Token, homogeneous Token) type digital assets as child digital assets, supported through the following interfaces:
(14) transferring FT-type digital assets
TransferFT(uint256_fromTokenId,address_to,address_FTContract,uint256_value)
Where _ fromTokenId is the roll-out account for the FT digital assets, _ to is the parent digital asset to which the received FT digital asset belongs, _ ftcontrast is the FT digital asset contract to be transferred, _ value is the number of FT digital assets transferred.
(15) Viewing FT digital asset balances
balanceOfFT(uint256_tokenId,address_FTContract)
The interface looks at the balance of the FT digital assets owned by the digital assets corresponding to the token id, _ ftcontrast is the corresponding FT digital asset contract.
(16) Receiving FT digital assets
tokenFallback(address_from,uint256_value,bytes_data)
Where _ from is the original account of the FT digital asset, _ value is the number of FT digital assets transferred, _ data is the parent digital asset id header field that receives the digital asset.
(17) Returning a contract address for a digital asset holding a particular FT digital asset
FTContractByIndex(uint256_tokenId,uint256_index)
Wherein _ token Id is the digital asset id with query and _ value is the FT digital asset serial number held by the digital asset.
The protocol supports the production, removal and destruction of digital assets through the following interfaces:
(18) producing new digital assets
mint(address_to,uint256_tokenId)
Where _ to is the owner of the digital asset and _ tokenId is the id of the newly produced digital asset.
(19) Removing digital assets owned by a particular account from the account
_removeMUToken(address_from,uint256_tokenId)
Where _ from is the ownership account of the digital asset to be removed and _ tokenId is the digital asset id to be removed.
(20) Destroying existing digital assets
burn(uint256_tokenId)
Where _ token Id is the digital asset id to be destroyed.
The protocol can support block chain-based digital asset transaction and support a digital asset creator to acquire royalties from subsequent transaction of the digital asset, and the functions are realized based on the following interfaces:
(21) paying royalty
RecievedRoyalties(address creator,address buyer,uint256 amount)
Wherein creator is the digital asset creator account, layer is the current purchaser of the digital asset, and amount is the royalty proportion paid by the purchaser to the creator.
(22) Copyright tax transaction recording certificate
royaltiesRecieved(address_creator,address_buyer,uint256_amount)
Wherein creator is the digital asset creator account, layer is the current purchaser of the digital asset, and amount is the royalty proportion paid by the purchaser to the creator.
(23) Checking whether digital asset contracts support royalty payments
hasRoyalties(uint256_tokenId)
Whether the digital assets corresponding to the _ token Id have royalties or not can be checked by calling the interface.
(24) Viewing specific information of digital assets containing royalties
function royaltyInfo(uint256_tokenId)
The interface returns royalty proportions and payment objects contained in the digital assets corresponding to the _ token Id.
To be compatible with the ERC721 standard, other interfaces that must be implemented include:
(25) authorization of an account for operation rights on a certain piece of digital asset:
approve(address_to,uint256_tokenId)
wherein _ to is an authorized account, and _ token Id is an id corresponding to the digital asset;
(26) granting the account operating rights to all digital assets:
setApprovalForAll(address_operator,bool_approved)
wherein, the _ operator is an account address, when the _ approved is true, the _ operator is authorized to have all digital asset rights, and when the _ approved is false, all digital asset rights of the _ operator are cancelled.
(27) And inquiring the authorization condition:
isApprovedForAll(address_owner,address_operator)
wherein _ owner is the MUT owner account address and _ operator is the account address, if _ operator is authorized by _ owner, return true, otherwise return false.
(28) Number of digital assets held in the return account:
balanceOf(address_owner,uint256_id)
where _owneris the account address and _idis the digital asset id that needs to be queried.
(29) Batch return accounts hold digital asset types and quantities:
functionbalanceOfBatch(address[]calldata_owners,uint256[]calldata_ids)
wherein _ownersis a list of accounts, and _idsis a list of digital asset ids to be queried.
(30) Returning the name of the digital asset:
name()
(31) returning abbreviated names (symbols) of digital assets:
symbol()
(32) returning the name that the MUT points to the digital content:
getDigitalAssetName(uint256_tokenId)
(33) returning descriptions of MUTs pointing to digital content:
getDigitalAssetDescription(uint256_tokenId)
(34) link _ url of digital content of query MUT:
getDigitalAsset(uint256_tokenId)
the interface returns an external URL, the URL corresponds to a description MUT metadata JSON file after domain name resolution and identification, and the JSON format is as follows:
Figure BDA0003535919570000181
to support the down-link coordination, the interfaces that need to be implemented include:
(35) downloading:
crosschain_download(uint256_tokenId)
wherein _tokenIdis the digital asset id to be queried; calling the function will automatically identify the transfer authority identification bit _ available corresponding to the MUT as "false";
(36) uploading:
crosschain_upload(_tokenId)
wherein _tokenIdis the id of the originally downloaded digital asset; after the function is called, the asset interest transfer functions such as transferSingle and the like are called, and meanwhile, the transfer authority identification bit _ available corresponding to the digital asset is identified as 'true'.
The embodiment also provides a method for realizing uplink and downlink collaborative management of the MUT chain based on the MAP protocol, which needs to rely on a management tool and a system matched with the management tool, wherein the management tool can be a software tool such as a wallet, a browser and the like, and is used for providing an uplink interface for a user to operate and providing the user with assistance of downloading (encoding) and uploading (decoding) of a downlink link download file.
The chain uplink and downlink cooperative management of the MUT is: the supported MUT is downloaded by the user offline through the management tool and transferred, exchanged outside the original blockchain, including offline and circulated on other blockchains that do not support the MAP protocol, and can be uploaded back to the original blockchain.
First, download step
1. The management tool calls a download interface function cross _ download () of the corresponding digital asset under the corresponding account of the download user to the corresponding block chain according to the digital asset ID of the MUT to be downloaded provided by the download user and the block chain identifier of the block chain bearing the MUT;
2. after a cross _ download () interface function of the MUT on the block chain is called, a transfer authority identification position _ available corresponding to the MUT is identified as 'false'; setting the transaction and transfer interfaces corresponding to the MUT, such as transfer Single () and other interfaces, as non-invokable; meanwhile, the block chain feeds back all data contents corresponding to the MUT to a management tool;
3. after the management tool acquires the data content of the MUT, packaging all the data content into a file, namely: downloading the bulk file by a chain; the packaging of the chain download file must follow a set of encoding encryption standards (such as AES, RSA, ECC, etc.), and complete the private Key encryption operation based on the encryption Key MUT _ Key provided by the download user;
4. and the downloading user authorizes the private key of the block chain account of the management tool (or sets the character on the management tool chain as operator and sets the intelligent contract to complete partial authority transfer or asset transfer) so that the management tool can change and call the MUT state on the original block chain when uploading the MUT to the block chain.
Second, uploading step
The uploading of the MUT to the block chain is divided into four cases, namely "uploading back to an original block chain", "uploading to other block chains supporting a MAP protocol", "uploading to a block chain not supporting a MAP protocol but supporting an NFT protocol such as ERC 721", and "uploading to a block chain not supporting a MAP protocol and an NFT protocol such as ERC 721", and the management tool determines corresponding specific situations according to a target block chain identifier provided by an uploading user in combination with previous data of the block chain.
A. When the original block chain is uploaded and returned, the method comprises the following steps:
1. the management tool uploads the file based on a chain download file corresponding to the MUT to be uploaded and provided by an uploading user, and the uploading user needs to provide an encryption Key MUT _ Key corresponding to the MUT to finish decoding during uploading;
2. after decoding is successful, the management tool calls an uploading interface function crosschain _ upload () of the original MUT on the block chain, after the uploading interface function is called by times, an identification position _ available corresponding to the transfer MUT is identified as 'true', and a transaction and transfer interface corresponding to the MUT, such as transfer Single (), is made available;
3. the management tool account calls transfer Single () by user authorization or operator identity, transfers MUT to uploading user, the MUT in the original owner account of MUT disappears; or changing the new owner into an uploading user, and removing the MUT under the name of the original owner by calling _ removeMUToken; by the two methods, the transfer of the MUT is completed, and the digital assets are transferred from the original owner account to the corresponding account of the uploading user.
B. When uploading to other block chains supporting the MAP protocol, the method comprises the following steps:
1. the management tool uploads the file based on a chain download file corresponding to the MUT to be uploaded and provided by an uploading user, and the uploading user needs to provide an encryption Key MUT _ Key corresponding to the MUT to finish decoding during uploading;
2. after decoding is successful, a data structure corresponding to the MUT is established on the target block chain, and all data files in the chain download file corresponding to the MUT are copied to realize reproduction of the original MUT data;
identifying the identification position corresponding to the MUT as 'downloaded from other chains'; setting a transaction and transfer interface corresponding to the MUT, such as transferSingle () and the like, as available; changing the current owner of the MUT into the current MUT uploading user; identifying the original position init _ chain of the MUT as the identification information of the MUT original block chain carried in the chain download file;
3. and after the management tool receives the signaling, the management tool calls a function burn () of destroying the existing digital asset interface of the MUT on the original block chain by using the authorization of the original owner of the MUT during downloading or using the identity of an operator to discard the MUT on the original block chain, thereby finishing the cross-chain transfer of the MUT.
C. When uploading to a block chain which does not support the MAP protocol but supports the ERC721 and other NFT protocols, two different methods can be selected according to user requirements:
the method comprises the following steps:
1. the management tool uploads the file based on a chain download file corresponding to the MUT to be uploaded and provided by an uploading user, and the uploading user needs to provide an encryption Key MUT _ Key corresponding to the MUT to finish decoding during uploading;
2. after decoding is successful, creating an NFT asset based on ERC-721 protocol on a target block chain, and copying a data file in a chain download file corresponding to the MUT into the NFT, wherein the method comprises the following steps:
a) for the data part of the MUT data item, in which the MAP protocol is overlapped with the ERC-721, the MUT copies the data part to the NFT in a one-to-one correspondence manner;
b) copying data items which exist in the MUT but do not exist in the ERC protocol into the corresponding NFT according to the MUT data format;
c) the identifier corresponding to the download is identified as "downloaded from other chains"; setting a transaction and transfer interface corresponding to the MUT, such as transferSingle () and the like, as available; changing the current owner of the MUT into the current MUT uploading user; and identifying the original position init _ chain of the MUT as the identification information of the MUT original block chain carried in the chain download file.
3. And after the new NFT on the target block chain is successfully created, sending a signaling to a management tool, calling a function burn () of the destroyed existing digital asset interface of the MUT on the original block chain by using the authorization of the original owner of the MUT during downloading after the management tool receives the signaling, abandoning the MUT on the original block chain, and finishing the chain-crossing transfer of the MUT.
The second method comprises the following steps:
and creating a new NFT on the target block chain, taking a chain download file corresponding to the MUT to be uploaded as a digital content file corresponding to the NFT, and storing the digital content file in the distributed storage system.
In the second method, the user obtains the MUT file by obtaining the NFT; after obtaining the MUT file, the user opens the MUT file by using a management tool and can upload the MUT file to an original block chain and the like.
In the second method, only the link download file is stored in the target block link, without changing the owner of the corresponding MUT, the owner is changed to upload the link to the block link supporting the MAP protocol, or to upload the link to the block link supporting the NFT protocol such as ERC 721.
D. When uploading to a block chain which does not support the MAP protocol and the NFT protocol such as ERC 721:
and creating a new digital asset on the target block chain, taking a chain download body file corresponding to the MUT to be uploaded as a digital content file corresponding to the digital asset, and storing the digital content file in the distributed storage system.
In the method, a user obtains the MUT file by obtaining the digital assets; after obtaining the MUT file, the user opens the MUT file by using a management tool and can upload the MUT file to an original block chain and the like.
In the method, only the link download file is stored on the target block chain, the owner of the corresponding MUT is not changed, and the owner is changed to upload the link to the block chain supporting the MAP protocol, or upload the link to the block chain supporting the NFT protocols such as the ERC721 and the like through the method I in the case C.

Claims (8)

1. A chain uplink and downlink coordinated digital asset management method for metastic application, when downloading a digital asset from a chain, comprising:
the management tool calls a downloading interface function of the corresponding digital asset under the corresponding account of the downloading user to the corresponding block chain according to the ID of the digital asset to be downloaded provided by the downloading user and the block chain identification bearing the digital asset;
after the download interface function of the digital assets on the blockchain is called, the transaction and transfer interface function corresponding to the digital assets is set to be non-callable, and meanwhile, the blockchain feeds back all digital contents corresponding to the digital assets to a management tool;
after the management tool acquires the digital contents, packaging all the digital contents into a chain download object file, and finishing private key encryption operation based on an encryption key provided by a download user;
after the chain download file is packaged, the management tool obtains partial authority of the corresponding digital asset, and the partial authority is used for changing and calling the state of the digital asset on the block chain originally bearing the digital asset when the management tool uploads the digital asset.
2. A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is an original block chain bearing the digital assets, the method is characterized in that:
the management tool completes decoding according to a chain download carrier file and an encryption key provided by an uploading user, wherein the chain download carrier file is generated when the digital assets are downloaded from the chain according to the chain uplink and downlink collaborative digital asset management method for the metauniverse application in claim 1;
after decoding is successful, the management tool calls an uploading interface function of the digital asset on the block chain, and then the transaction and transfer interface function corresponding to the digital asset is set to be callable;
and the management tool calls a transaction and transfer interface function corresponding to the digital asset on the block chain, and transfers the digital asset from the original owner account to the account corresponding to the uploading user through the transaction and transfer interface function.
3. A chain uplink and downlink collaborative digital asset management method for meta-space application is used for uploading a digital asset to a target block chain, and when the target block chain is a block chain which originally carries the digital asset, the method is characterized in that:
the management tool completes decoding according to a chain download carrier file and an encryption key provided by an uploading user, wherein the chain download carrier file is generated when the digital assets are downloaded from the chain according to the chain uplink and downlink collaborative digital asset management method for the metauniverse application in claim 1;
after decoding is successful, corresponding digital assets are created on a target block chain based on digital contents of the digital assets, then transaction and transfer interface functions corresponding to the digital assets are set to be invokable on the target block chain, and owners of the digital assets are changed into accounts corresponding to uploading users;
after the digital assets on the target block chain are successfully created, a signaling is sent to a management tool, the management tool calls a function of destroying the existing digital asset interface of the corresponding digital assets on the original block chain after receiving the signaling, and the digital assets on the original block chain are discarded by destroying the existing digital asset interface function.
4. A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is a block chain which originally bears the digital assets, the method is characterized in that:
the management tool completes decoding according to a chain download carrier file and an encryption key provided by an uploading user, wherein the chain download carrier file is generated when the digital assets are downloaded from the chain according to the chain uplink and downlink collaborative digital asset management method for the metauniverse application in claim 1;
after decoding is successful, creating an NFT asset on a target block chain, and copying a data file in a chain download file into the NFT;
setting a transaction and transfer interface function corresponding to the NFT asset as callable on a target block chain, and changing an owner of the digital asset into an account corresponding to an uploading user;
after the NFT assets on the target block chain are successfully created, a signaling is sent to a management tool, the management tool calls a destroyed existing digital asset interface function of the corresponding digital assets on the original block chain after receiving the signaling, and the digital assets on the original block chain are abandoned through the destroyed existing digital asset interface function.
5. A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is a block chain which originally bears the digital assets, the method is characterized in that:
creating an NFT asset on a target block chain, taking a chain download file corresponding to the digital asset as a digital content file corresponding to the NFT, and storing the digital content file in a distributed storage system;
wherein the downlinked carrier file is generated when the digital asset is downloaded from the chain according to the method for managing a linked uplink and downlink collaborative digital asset for a metastic application according to claim 1.
6. A chain uplink and downlink collaborative digital asset management method for metaclass application is used for uploading digital assets to a target block chain, and when the target block chain is a block chain which originally bears the digital assets, the method is characterized in that:
creating a new digital asset on the target block chain, taking a chain download file corresponding to the digital asset as a digital content file corresponding to the new digital asset, and storing the digital content file in a distributed storage system;
wherein the downlinked carrier file is generated when the digital asset is downloaded from the chain according to the method for managing a linked uplink and downlink collaborative digital asset for a metastic application according to claim 1.
7. A digital asset management protocol, characterized by: the protocol defines a download interface function and a transaction and transfer interface function in the method for managing the meta-space-oriented uplink and downlink collaborative digital assets according to claim 1, and defines an upload interface function, a transaction and transfer interface function and a destroy existing digital asset interface function in the method for managing the meta-space-oriented uplink and downlink collaborative digital assets according to any one of claims 2 to 6.
8. The digital asset management protocol of claim 7, wherein the protocol defines the following interface functions:
(1) single piece digital asset transfer:
transferSingle(address_operator,address_from,address_to,uint256_tokenId,uint256_value,boolean_available)
wherein, the _ from and the _ to are respectively an exit and an entry of the digital asset, the _ token Id is the transferred digital asset id, and the uint256_ value is the number of the transferred digital assets; when the _ available is false, the function is not invokable;
(2) safe transfer of a single piece of digital assets:
safeTransferFrom(address_from,address_to,uint256_id,uint256_value,bytes calldata_data,boolean_available)
wherein _ from is a transfer-out account of the digital assets, ownership of the digital assets must be possessed, _ to is a transfer-in account of the digital assets, _ tokenId is a transferred digital asset id, _ uin 256_ value is the number of the transferred digital assets, and _ data is other text information transferred to a receiving account callback function; when the _ available is false, the function is not invokable;
(3) digital asset packaging transfer:
transferBatch(address_operator,address_from,address_to,uint256[]_ids,uint256[]_values,boolean_available)
the authorized account of the digital assets of the operator, from and to are the transferring party and the transferring party of the digital assets respectively, ids is a list of the id of the digital assets to be transferred, and values is the number of each digital asset in the list of the digital assets to be transferred; when the _ available is false, the function is not invokable;
(4) packaging and safely transferring the digital assets:
safeBatchTransferFrom(address_from,address_to,uint256[]calldata_ids,uint256[]calldata_values,bytes calldata_data,boolean_available)
wherein, the 'from' is the transfer-out account of the digital assets, the ownership of the digital assets must be possessed, the 'to' is the transfer-in account of the digital assets, the 'ids' is the list of the digital assets id to be transferred, the 'values' is the number of each digital asset in the list of the digital assets to be transferred, and the 'data' is other literal information transferred to the call-back function of the receiving account; when the _ available is false, the function is not invokable;
(5) sub-digital asset transfer
transferChild(int256_fromTokenId,address_to,address_childContract,uint256_childTokenId,boolean_available)
Wherein _ fromTokenId is the parent digital asset id of the digital asset to be transferred, _ to is the transfer-in account of the digital asset, _ childcontinuously is the contract address of the digital asset, and _childtokenidis the id of the digital asset; when the _ available is false, the function cannot be called;
(6) transferring sub-digital assets to specific digital assets
transferChildToParent(uint256_fromTokenId,address_toContract,uint256_toTokenId,address_childContract,uint256_childTokenId,bytes_data,boolean_available)
Wherein fromTokenId is an upper parent digital asset to be received, toconteract is a contract address of the upper parent digital asset to be received, tototokenid is an id of the upper parent digital asset to be received, childContract is a contract address of the digital asset to be transferred, and childTokenId is an id of the digital asset; when the _ available is false, the function is not invokable;
(7) sub-digital asset reception
receiveChild(int256 indexed_from,address_toTokenId,address_childContract,uint256_childTokenId)
Wherein _ from is an original owning account of the digital asset to be received, _ toTokenId is a parent digital asset of the digital asset to be received, _ childContract is a contract address of the digital asset, and _ childTokenId is an id of the digital asset;
(8) returning root digital assets to which a particular digital asset id belongs
rootOwnerOf(uint256_tokenId)
Wherein _tokenIdis id of the digital asset;
(9) returning root digital assets attributed to a particular digital asset
rootOwnerOfChild(address_childContract,uint256_childTokenId)
Wherein _ childContract is the contract address of the digital asset and _ childTokenId is the id of the digital asset;
(10) parent digital asset returning digital asset
ownerOfChild(address_childContract,uint256_childTokenId)
Wherein _ childContract is the contract address of the digital asset and _ childTokenId is the id of the digital asset;
(11) returning the total number of the subordinate digital assets of the specific digital asset id:
totalChildContracts(uint256_tokenId)；
(12) returning corresponding digital asset contract address through digital asset id and digital asset sequence number
childContractByIndex(uint256_tokenId,uint256_index)
Wherein _ index is the serial number of the digital asset;
(13) returning id of digital asset
childTokenByIndex(uint256_tokenId,address_childContract,uint256_index)
(14) Transferring FT-type digital assets
TransferFT(uint256_fromTokenId,address_to,address_FTContract,uint256_value)
Wherein _ fromTokenId is the roll-out account of the FT digital assets, _ to is the parent digital asset to which the received FT digital assets belongs, _ ftcontrast is the FT digital asset contract to be transferred, and _valueis the number of transferred FT digital assets;
(15) viewing FT digital asset balances
balanceOfFT(uint256_tokenId,address_FTContract)
The interface checks the balance of the FT digital assets owned by the digital assets corresponding to the _ token Id, and the _ FTContract is a corresponding FT digital asset contract;
(16) receiving FT digital assets
tokenFallback(address_from,uint256_value,bytes_data)
Wherein _ from is the original account of the FT digital assets, _ value is the number of FT digital assets transferred, _ data is the parent digital asset id header field that receives the digital assets;
(17) returning a contract address for a digital asset holding a particular FT digital asset
FTContractByIndex(uint256_tokenId,uint256_index)
Wherein, the _ token Id is the digital asset id with query, and the _ value is the FT digital asset serial number held by the digital asset;
(18) producing new digital assets
mint(address_to,uint256_tokenId)
Wherein _ to is the owner of the digital asset and _ tokenId is the id of the newly produced digital asset;
(19) removing digital assets owned by a particular account from the account
_removeMUToken(address_from,uint256_tokenId)
Wherein _ from is an ownership account of the digital asset to be removed, and _ tokenId is a digital asset id to be removed;
(20) destroying existing digital assets
burn(uint256_tokenId)
Wherein the _ token Id is a digital asset id to be destroyed;
(21) paying royalty
RecievedRoyalties(address creator,address buyer,uint256 amount)
Wherein creator is the account of the creator of the digital assets, layer is the current purchaser of the digital assets, and amount is the royalty proportion paid to the creator by the purchaser;
(22) copyright tax transaction recording certificate
royaltiesRecieved(address_creator,address_buyer,uint256_amount)
The creator is an account of a digital asset creator, the layer is a current purchaser of the digital asset, and the amount is a royalty proportion paid by the purchaser to the creator;
(23) checking whether digital asset contracts support royalty payments
hasRoyalties(uint256_tokenId)
Whether the digital assets corresponding to the _ token Id have royalties or not can be checked by calling the interface;
(24) viewing specific information of digital assets containing royalties
function royaltyInfo(uint256_tokenId)
The interface returns the royalty proportion and the payment object contained in the digital asset corresponding to the _ token Id;
(25) authorization of an account for operation of a digital asset:
approve(address_to,uint256_tokenId)
wherein _ to is an authorized account, and _ token Id is an id corresponding to the digital asset;
(26) granting the account operating rights to all digital assets:
setApprovalForAll(address_operator,bool_approved)
wherein, the _ operator is an account address, when the _ approved is true, the _ operator is authorized to have all digital asset permissions, and when the _ approved is false, all digital asset permissions of the _ operator are cancelled;
(27) and inquiring the authorization condition:
isApprovedForAll(address_owner,address_operator)
wherein, the _ owner is the account address of the digital asset owner, the _ operator is the account address, if the _ operator is authorized by the _ owner, the value is returned, otherwise, the value is returned;
(28) number of digital assets held in the return account:
balanceOf(address_owner,uint256_id)
wherein _owneris an account address and _idis a digital asset id to be queried;
(29) batch return account holds digital asset types and quantities:
function balanceOfBatch(address[]calldata_owners,uint256[]calldata_ids)
wherein, owners is a group of account lists, ids is a digital asset id list to be inquired;
(30) returning the name of the digital asset:
name()
(31) returning the abbreviated name of the digital asset:
symbol()
(32) returning the name of the digital asset pointing to the digital content:
getDigitalAssetName(uint256_tokenId)
(33) returning a description of the digital asset pointing to the digital content:
getDigitalAssetDescription(uint256_tokenId)
(34) link _ url of digital content of query digital asset:
getDigitalAsset(uint256_tokenId)
the interface returns an external URL, the URL corresponds to a digital asset metadata JSON file after domain name resolution and identification, and the JSON format is as follows:
{
"name":"_name",
"description":"_description",
"image":"_url",
}；
to support the down-link coordination, the interfaces that need to be implemented include:
(35) downloading:
crosschain_download(uint256_tokenId)
wherein _tokenIdis the digital asset id to be queried; calling the function can automatically identify the transfer authority identification bit _ available corresponding to the digital asset as 'false';
(36) uploading:
crosschain_upload(_tokenId)
wherein _tokenIdis the id of the originally downloaded digital asset; after the function is called, the asset interest transfer functions such as transferSingle and the like are called, and meanwhile, the transfer authority identification bit _ available corresponding to the digital asset is identified as 'true'.
CN202210226827.9A 2022-03-08 2022-03-08 Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application Pending CN114707973A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210226827.9A CN114707973A (en) 2022-03-08 2022-03-08 Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210226827.9A CN114707973A (en) 2022-03-08 2022-03-08 Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application

Publications (1)

Publication Number Publication Date
CN114707973A true CN114707973A (en) 2022-07-05

Family

ID=82169320

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210226827.9A Pending CN114707973A (en) 2022-03-08 2022-03-08 Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application

Country Status (1)

Country Link
CN (1) CN114707973A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116108506A (en) * 2023-04-12 2023-05-12 广东奥飞数据科技股份有限公司 Meta-universe digital asset security management system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116108506A (en) * 2023-04-12 2023-05-12 广东奥飞数据科技股份有限公司 Meta-universe digital asset security management system
CN116108506B (en) * 2023-04-12 2023-06-23 广东奥飞数据科技股份有限公司 Meta-universe digital asset security management system

Similar Documents

Publication Publication Date Title
US20230360036A1 (en) Blockchain-implemented method and system for access control on remote internet-enabled resources
CN100576148C (en) Be used to provide the system and method for security server cipher key operation
US7814025B2 (en) Methods and apparatus for title protocol, authentication, and sharing
US8086758B1 (en) Systems and methods for interconnecting media applications and services with centralized services
US7996488B1 (en) Systems and methods for interconnecting media applications and services with automated workflow orchestration
US7720918B1 (en) Systems and methods for interconnecting media services to an interface for transport of media assets
WO2018213672A1 (en) Decentralized digital content distribution system and process using block chains
US20030233549A1 (en) File exchange apparatus, personal information entry/introduction server, transmission controlling method, and program therefor
US20080167994A1 (en) Digital Inheritance
JP2004127307A (en) Control system for access to and use of compound digital work
CN101002224A (en) Transmission history dependency processor
CN113127811B (en) Cultural relic digital resource safe sharing method, system and information data processing terminal
WO2003098398A2 (en) Methods and apparatus for a title transaction network
CN109388957A (en) Information transfer method, device, medium and electronic equipment based on block chain
CN103366304A (en) Method, device and equipment for transfer of virtual commodity use right
US20230109369A1 (en) First copyright holder authentication system using blockchain, and method therefor
WO2001006425A1 (en) Copyright information management system
CN114707973A (en) Method and protocol for managing downlink and uplink coordinated digital assets of chain oriented to metauniverse application
JP2003186756A (en) Method, device, and program for setting limitation on use of data and recording medium with program recorded thereon
EP1903467A2 (en) Method, apparatus, and system for transmitting and receiving inter-device content right objects
KR20220076948A (en) System and method for managing intellectual property based on blockchain
CN113806817B (en) Method for constructing twin NFT, NFT protocol and system for full trusted storage
CN1941778B (en) Third party access gateway for telecommunications services
US20240054481A1 (en) Content Rights Management Systems and Methods Using Trusted Ledgers
CN116305219B (en) Controllable, credible and rotatable personal information authorization processing method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination