Mirror image resource processing method and device, nonvolatile storage medium, and processor

Abstract

The application discloses a mirror resource processing method and device, a nonvolatile storage medium and a processor. The method comprises the following steps: receiving a request message of a token of a mirror resource for calling a resource management container from a target account, wherein the resource management container is used for storing at least issuer information of the mirror resource; under the triggering of the request message, obtaining the authority of the target account, and in the case that the target account has the authority of calling the mirror resource, determining a mode of allowing the target account to operate the mirror resource. The application solves the technical problem of security risks existing in the issuance and calling process of the mirror resource.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a method and apparatus for processing mirrored resources, a non-volatile storage medium, and a processor. Background Technology

[0002] Docker, or Virtual Environment Container, is an open-source application container engine. Docker packages an application's executable file, dependencies, and operating system files into a lightweight, portable image, fixing the application's runtime environment. Simultaneously, the image can reproduce the same runtime environment in other environments, greatly facilitating operations and application deployment. A Docker image consists of multiple read-only image layers. Each instruction in the text document (Dockerfile) containing the commands to assemble the image creates a new layer, and each layer only records the changes made within its own layer. After a container is started, Docker adds a read-write layer on top, saving all changes made within the container, such as writing logs, modifying, and deleting files, to this layer. Container images are commonly used for software resource delivery. However, during software image distribution and transactions, there is a risk of software piracy or cracking. Piracy or cracking severely damages the rights of the distributor. Furthermore, container images may be maliciously modified or infected with malware during distribution, and users cannot verify their origin and security, thus posing security risks in software image distribution and transactions.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method and apparatus for processing image resources, a non-volatile storage medium, and a processor, to at least solve the technical problem of security risks in the issuance and retrieval process of image resources.

[0005] According to one aspect of the embodiments of this application, a method for processing container image resources is provided, comprising: receiving a request message from a target account for a token for invoking an image resource in a resource management container, wherein the resource management container is used to store at least the issuer information of the image resource; upon triggering the request message, obtaining the permissions of the target account, and determining that the target account is allowed to operate on the image resource if the target account has the permission to invoke the image resource.

[0006] Optionally, obtaining the target account's permissions includes: obtaining a first identifier of the mirror resource pre-stored on the blockchain platform, and determining a second identifier of the mirror resource obtained from the target account, wherein the first identifier includes: a hash value determined at least based on the mirror resource and the issuer information of the mirror resource; if the first identifier and the second identifier are consistent, it is determined that the target account has the permission to call the mirror resource.

[0007] Optionally, obtaining the mirror resource corresponding to the requested information from the blockchain includes: determining the first smart contract of the blockchain, and obtaining the mirror resource corresponding to the first identifier through the first smart contract.

[0008] Optionally, the token for the image resource is determined by: acquiring a preset number of image resources for resource management containers, the image resources including resource management container information and issuer information; and determining the token based on the image resources.

[0009] Optionally, determining the token based on the mirror resource includes: calculating the hash value of the mirror resource and storing the mirror resource in the first database of the blockchain; determining the token based on the name, hash value, and issuer information of the mirror resource.

[0010] Optionally, before receiving a request message from the target account for tokens used to invoke the image resources of the resource management container, the process includes: receiving a request message from the target account for obtaining tokens, and determining the address of the target account; determining the second smart contract and the third smart contract of the blockchain; obtaining a preset number of virtual resources through the second smart contract, wherein the preset number of virtual resources are stored at the address of the target account; and after confirming the acquisition of the preset number of virtual resources, transferring the permission to invoke the image resources to the address of the target account through the third smart contract.

[0011] According to another aspect of the embodiments of this application, a processing apparatus for image resources is provided, comprising: a receiving module, configured to receive a request message from a target account for a token of an image resource for invoking a resource management container, wherein the resource management container is configured to store at least the issuer information of the image resource; and an obtaining module, configured to obtain the permissions of the target account upon being triggered by the request message, and, if the target account has the permission to invoke the image resource, determine that the target account is allowed to operate on the image resource.

[0012] Optionally, the acquisition module is further configured to acquire a first identifier of the mirror resource pre-stored on the blockchain platform, and determine a second identifier of the mirror resource acquired from the blockchain, wherein the first identifier includes: a hash value determined at least based on the mirror resource and the issuer information of the mirror resource; if the first identifier and the second identifier are consistent, it is determined that the target account has the permission to call the mirror resource.

[0013] According to another aspect of the embodiments of this application, a non-volatile storage medium is provided, the non-volatile storage medium including a stored program, wherein, when the program is running, it controls the device where the non-volatile storage medium is located to execute the above-mentioned image resource processing method.

[0014] According to another aspect of the embodiments of this application, a processor is provided for running a program stored in a memory, wherein the program executes the above-described processing method for image resources during runtime.

[0015] In this embodiment, a request message is received from a target account for a token used to invoke a resource management container for image resources. The resource management container is used to store at least the issuer information of the image resources. Upon triggering the request message, the target account's permissions are obtained. If the target account has the permission to invoke the image resources, the method for allowing the target account to operate on the image resources is determined. Since the image resources are obtained from the blockchain, the security of invoking the image resources can be improved. Furthermore, since the image resources are stored in the blockchain, the security of the image resource issuance process is also provided, thereby solving the technical problem of security risks in the issuance and invoking process of image resources. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for a method of processing mirrored resources according to an embodiment of this application.

[0018] Figure 2 This is a flowchart of a method for processing mirrored resources according to an embodiment of this application;

[0019] Figure 3 A structural diagram of a mirror resource processing apparatus according to an embodiment of this application;

[0020] Figure 4 This is a flowchart illustrating the distribution of mirror resources according to an embodiment of this application;

[0021] Figure 5 This is a schematic diagram illustrating the generation of a non-fungible token according to an embodiment of this application;

[0022] Figure 6 This is a schematic diagram illustrating the issuance and invocation of mirror resources according to an embodiment of this application. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] For ease of understanding, the terms blockchain, Ethereum, ERC721, and smart contracts mentioned in the embodiments of this application are explained as follows: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. After its inception, blockchain technology was first applied to risk control of virtual currencies. Essentially, it is a decentralized database. As the underlying technology of virtual currencies, blockchain is also a series of data blocks linked using cryptographic methods. Each data block contains information about a batch of virtual currency network transactions, used to verify the validity of the information, achieve anti-counterfeiting effects, and generate the next block. Decentralization: In a network or system with numerous distributed network nodes, nodes can freely connect to form new connection units, and any node may become a temporary center, but it does not possess mandatory central control functions. Because blockchain can maintain data integrity, and the data stored on the blockchain is shared by all participants, blockchain is also a distributed shared ledger and database that permanently records and stores transaction data in chronological order, and has the characteristics of decentralization, immutability, full traceability, collective maintenance, and transparency. Based on the aforementioned characteristics of blockchain, this application embodiment integrates blockchain technology with the issuance of software container image information to enhance the security of the container image issuance transaction process.

[0026] Fungible tokens (Tokens) are fungible, uniform tokens that can be infinitely divided. Non-fungible tokens (NFTs) are digital assets, each uniquely identifying an underlying asset, such as a unique artwork or rare trading card. Compared to fungible tokens, NFTs possess superior attributes like uniqueness, indivisibility, and immutability, making them commonly used to peg to specific assets and prove ownership of digital assets. They are primarily applied in fields such as games, art, collectibles, domain names, virtual assets, identity verification, digital music, and digital certificates. Essentially, a blockchain token is a smart contract (a piece of software code) that includes both data and the manipulation of that data. These smart contracts are not just software code; they adhere to industry standards, such as unified data structures and data manipulation methods. Therefore, they are recognized within the industry and can be used with various tools and software for operation, browsing, and referencing, thus possessing characteristics such as transparency, oversight, and collaborative capabilities. For example, the data and operations of a standard ERC721 token can be viewed through a general blockchain explorer (third-party browser), and its open data structure and programming interface allow others to program it, thus forming an interface. For instance, a non-fungible token issued on one software platform can circulate in another software system for viewing and processing. Most NFT smart contracts have a function that returns metadata (such as NFT attributes) corresponding to its token identifier. The return value is typically a Uniform Resource Identifier (URI) on the cloud server run by the developer (e.g., example.com / nft / 2). If the content and medium of an NFT are controlled by such a server, then the NFT is centralized and suffers from impermanence and volatility issues.

[0027] The Ethereum Request for Comment (ERC) protocol, specifically ERC 721, defines an interface specification for the interaction and circulation of indivisible and unique tokens within the Ethereum ecosystem. This specification is essentially a smart contract on Ethereum, running on the Ethereum Virtual Machine (EVM), and possesses uniqueness and ownership transfer capabilities.

[0028] In the process of software image distribution and trading, the rights and interests of the issuer will be severely damaged if the software is pirated or cracked. Furthermore, container images may be maliciously tampered with or implanted with malware, and users find it difficult to verify their source and security, leading to security risks. This application provides a method to solve the above problems. Specifically, this application implements encrypted authentication through smart contracts and the Ethereum Non-Fungible Token Standard (Ethereum Request for Comment, ERC-721), encrypting and storing the container image and issuer information in the form of smart contracts on a public blockchain. It proposes a scheme for the issuance, trading, and use of software container images, achieving traceability and verifiability of image issuance and ensuring its authority and security. The following is a detailed description.

[0029] According to an embodiment of this application, an embodiment of a method for processing mirror resources is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, cloud servers, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for processing mirrored resources is shown. Figure 1 As shown, the computer terminal 10 (or mobile device 10) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0032] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the image resource processing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the above-mentioned image resource processing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0033] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0034] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0035] According to an embodiment of this application, an embodiment of a method for processing mirrored resources is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] Figure 2 This is a flowchart of a method for processing mirrored resources according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0037] Step S202: Receive a request message from the target account for a token used to invoke the image resource of the resource management container, wherein the resource management container is used to store at least the issuer information of the image resource.

[0038] For example, when a user needs to perform actions such as deployment, they initiate a request through the local platform interface corresponding to the blockchain platform. After receiving the user's request, the blockchain continues to execute the following steps. The aforementioned blockchain platform can be a computer device or a group of computer devices located on the network side, but is not limited to this.

[0039] Step S204: Upon triggering the request message, obtain the target account's permissions, and if the target account has the permission to access the image resources, determine that the target account is allowed to operate on the image resources.

[0040] For example, after receiving a user's request message, the blockchain platform uses a relevant blockchain explorer (such as Etherscan.io) to find the smart contract, calls the getApproved function in ERC721 for verification to determine if the user has the necessary permissions. After confirming that the user has the permission to access the image resource, the platform pulls the blockchain image corresponding to the user's token and queries the hash value of the user's token through the blockchain explorer to determine if this hash value matches the hash value used to pull the image. Only when the hash value of the token matches the hash value used to pull the image can the user obtain the image resource and deploy it.

[0041] In the above process, the mirror resources are stored in a database linked to the blockchain. Accessing the mirror resources requires using the blockchain, which effectively avoids problems such as software tampering and malware implantation, thus improving the security of software distribution. In addition, the mirror resources are stored on the public blockchain in the form of non-fungible tokens. By leveraging the uniqueness of each non-fungible token to correspond to only one token, the software mirror resources are mapped, effectively avoiding software piracy and improving the security of the mirror resource distribution process. This solves the technical problems of security risks in the distribution and access of mirror resources.

[0042] In some embodiments, obtaining permissions for a target account includes the following steps: obtaining a first identifier of a mirror resource pre-stored on a blockchain platform, and determining a second identifier of the mirror resource obtained from the target account, wherein the first identifier includes a hash value determined at least based on the mirror resource and the issuer information of the mirror resource; if the first identifier and the second identifier are consistent, determining that the target account has the permission to invoke the mirror resource.

[0043] It should be noted that the second identifier can be calculated based on the hash value of the acquired mirror resource. Since the hash function is unique, only when the first identifier and the second identifier are consistent can it be proven that the same information is used when calculating the hash value of the first identifier and the hash value corresponding to the second identifier, thus proving that they represent the same resource.

[0044] According to an optional embodiment of this application, obtaining a mirror resource corresponding to a request information from a blockchain includes: determining a first smart contract of the blockchain, and obtaining the mirror resource corresponding to a first identifier through the first smart contract.

[0045] In this embodiment, after confirming that the user has the permission to call the image resource, the blockchain calls the image resource represented by the first identifier from the artifact library (i.e., the first database) through a smart contract, so that the user can perform operations such as deployment.

[0046] According to an optional embodiment of this application, the token for the image resource is determined by: acquiring a preset number of image resources of resource management containers, wherein the image resources include resource management container information and issuer information; and determining the token based on the image resources.

[0047] It is also important to note that resource management container information includes: information used to identify the identity of the resource management container, and information recording the operations performed within the container; issuer information refers to any information that can identify the issuer, such as the issuer's name or unified social credit code, and the issuer's information is stored in the image resource in the form of a digital identity.

[0048] This embodiment divides the creation of a mirror resource token into two steps. The first step is to obtain the information that the mirror resource should contain. The mirror resource should include mirror resource information. Before creating the mirror resource token, the issuer's Ethereum wallet address (issuer account address) is first determined using the following method: the issuer's digital wallet is created and a random string is obtained. This string is the issuer's private key. Since Ethereum uses elliptic curves (secp256k1), the private key is processed using an elliptic curve digital signature algorithm. The public key is obtained using the ECDSA algorithm. A hash algorithm (Keccak-256) is then used to calculate the hash value of the public key. The last 20 bytes of the hash value are the issuer's Ethereum wallet address. This Ethereum wallet address is mapped to the issuer's entity information to generate a digital identity, and the hash value of this digital identity is calculated. The issuer's entity information may include, but is not limited to, the issuer's company name and unified social credit code. The key-value pair mapping between the issuer's digital identity and the issuer's entity information, along with the hash value of this mapping, is stored locally on the platform managing the issuer and container image resources. This allows the platform to manage and differentiate multiple issuers and their corresponding image resources. The image resources are stored in a resource management container. The issuer confirms the total issuance of the container image, creates the container image resource, and uses it to initialize the smart contract for the image asset (i.e., prepares for creating the token for the image resource). The container's image resource contains information about the resource management container, the image resource itself, and records of operations performed within the container.

[0049] In other embodiments, determining a token based on a mirror resource includes the following operations: calculating the hash value of the mirror resource, storing the mirror resource in a first database of the blockchain; and determining the token based on the name, hash value, and issuer information of the mirror resource.

[0050] In this embodiment, the hash value of the image resource is calculated according to the method for calculating the hash value of the public key described above. After obtaining the hash value of the image resource, the decentralized and distributed storage characteristics of the blockchain are fully utilized to store the image resource and its corresponding hash value in different locations. The image resource is stored in a network space accessible through the blockchain (i.e., the first database, the artifact repository), and its corresponding hash value is saved on the public chain of the blockchain through a smart contract. The hash value can be used for image traceability and security verification. By verifying the image hash value, it is ensured that the issued image content is not maliciously tampered with, and the image issuance is traceable.

[0051] According to another optional embodiment of this application, before receiving a request message from a target account for a token to invoke the image resources of a resource management container, the method includes: receiving a request message from the target account for obtaining tokens, and determining the address of the target account; determining a second smart contract and a third smart contract of the blockchain; obtaining a preset number of virtual resources through the second smart contract, wherein the preset number of virtual resources are stored at the address of the target account; and after confirming that the preset number of virtual resources have been obtained, transferring the permission to invoke the image resources to the address of the target account through the third smart contract.

[0052] In this optional embodiment, a preferred method for obtaining tokens for mirror resources is provided. Before using the aforementioned tokens, users need to exchange for (i.e., obtain) the aforementioned tokens. When a user requests to exchange for the aforementioned tokens on the platform, the platform determines whether the user sending the exchange request has a digital wallet (i.e., an account on the Ethereum blockchain). If not, the platform links to the blockchain to create the user's digital wallet and maps the wallet address and corresponding relationship, that is, it assigns a wallet address to the user.

[0053] If the user sending the token exchange request has a digital wallet, their Ethereum wallet address is retrieved. Since the initial holder of all tokens is designated as the token issuer, and the exchanged tokens reside in the issuer's Ethereum wallet address (on the blockchain), the following operations are performed by linking to the public blockchain: The blockchain calls the ERC721 function for transferring tokens (i.e., the Transfer function) to request tokens from the issuer, sends a payment message to the target account, notifying the target account to pay for the token exchange, and after the target account (i.e., the user) pays a certain blockchain transaction fee (gasfee), the virtual image (i.e., the token) is transferred to the user's Ethereum wallet address. Next, the ERC721 function for confirming ownership (i.e., the ownerOf function) is called to verify the ownership of the token. The ID of the token transferred to the user's address is input into the ownerOf function. If the ownerOf function returns the ID to the user's address, it proves that the user owns the token. After this process, the user possesses the token of the image resource and the right to access the image resource. The aforementioned wallet is essentially a tool for managing the keys and addresses of blockchain nodes; among them, the address, as well as the Ethereum wallet address, wallet address, and target account address mentioned above, are all strings used by users on the blockchain to receive and store blockchain assets, which are combinations of numbers and letters.

[0054] Figure 3 This is a structural diagram of a mirror resource processing apparatus provided according to an embodiment of this application, such as... Figure 3As shown, the device includes: a receiving module 30, configured to receive a request message from a target account for a token used to invoke an image resource in a resource management container, wherein the resource management container is used to store at least the issuer information of the image resource; and an obtaining module 32, configured to obtain the target account's permissions upon triggering the request message, and, if the target account has the permission to invoke the image resource, determine that the target account is allowed to operate on the image resource.

[0055] In some embodiments, the acquisition module is further configured to acquire a first identifier of the mirror resource pre-stored on the blockchain platform, and determine a second identifier of the mirror resource acquired from the blockchain, wherein the first identifier includes: a hash value determined at least based on the mirror resource and the issuer information of the mirror resource; if the first identifier and the second identifier are consistent, it is determined that the target account has the permission to call the mirror resource. Based on the above embodiments, a specific implementation method is provided, which will be described below from the perspectives of the issuance and use of mirror resources.

[0056] Figure 4 This is a flowchart of the issuance of mirror resources according to the method of this embodiment. At the beginning of the process, the issuance of a digital wallet is executed. The issuer's digital wallet is created according to the method provided in the embodiment of this application to obtain a private key. The public key is obtained by using the ECDSA elliptic curve digital algorithm on the private key. The public key is calculated, and the last 20 bytes of the hash result are the issuer's Ethereum wallet address. The specific calculation process is as follows:

[0057] Public key=ECDSA(Private key)

[0058] A = Keccak - 256 (Public key)

[0059] Address=′0x′+last 20 bytes of A

[0060] Where A represents the hash value of the public key, Address represents the Ethereum wallet address, and "0x" represents hexadecimal, which converts the last 20 bytes of the public key hash value into a hexadecimal number.

[0061] The public and private keys mentioned above are a key pair obtained through an algorithm. Essentially, they are two strings: the public key is the publicly disclosed part of the key pair, while the private key is the private key. The public key is typically used to encrypt session keys, verify digital signatures, or encrypt data that can be decrypted using the corresponding private key. Key pairs obtained through this algorithm are guaranteed to be unique worldwide.

[0062] After obtaining the issuer's wallet address, it is mapped to the issuer's entity information to generate a digital identity. The mapping relationship between the issuer's digital identity and entity information, along with its hash value, is stored on a software platform (such as GitLab) that manages the issuer and container image resources. During the process of creating a local mapping relationship, the mapping relationship between the issuer's digital identity and entity information is a key-value pair mapping. Through this key-value pair relationship, physical information (i.e., the issuer's entity information) can be converted into corresponding digital information (i.e., the issuer's digital identity). The image resources are stored in a resource management container. The issuer confirms the total issuance of the container image, obtains the hash value of the image to be issued as the image identifier, and uploads the image resources to the artifact repository. The hash value of the image to be issued is then written to the public blockchain via a blockchain smart contract for notarization, and the process of generating image digital asset certificates continues.

[0063] Figure 5 This is a diagram illustrating the generation of nonfungible tokens (i.e., mirrored digital asset certificates) according to the Ethereum nonfungible token ERC-721 protocol, as shown below. Figure 5 As shown, the hash value of the aforementioned image, the image hash value, the image name, and the digital identity of the issuer (i.e., the issuer name) contained in the image resource are configured into the metadata of the non-fungible token. The image name is created along with the image resource during its creation, and each image resource has its own corresponding image name. The metadata is the identifier of the image resource, containing basic information about its elements. Storing the token in the form of metadata in the Ethereum contract saves storage resources. Deploying the smart contract on the chain allows for the issuance of the image's non-fungible token and the determination of its total issuance and whether it can be increased. All initial holders of the tokens are designated as the issuer, and the exchanged tokens are deposited into the issuer's wallet address.

[0064] Figure 6 This is a diagram illustrating the distribution and use of mirrored resources. (For example...) Figure 6As shown, the issuer publishes a blockchain mirror to the blockchain platform; the blockchain platform stores the identifier of the mirror resource and saves the blockchain mirror resource in the artifact repository; using the identifier of the mirror resource, a mirror digital asset certificate is generated according to the Ethereum non-fungible token ERC-721 protocol, and the main attributes of the mirror are configured in the token's metadata, including the mirror hash value, mirror name, and issuer information. Then, the mirror asset is put on the blockchain and deployed to the public blockchain, where the public blockchain issues the mirror's non-fungible token (mirror digital asset token). When a third-party user obtains a mirror resource, they send a request to the corresponding interface of the blockchain platform. The blockchain platform acquires ownership of the mirror asset stored in the issuer's address and transfers it to the third-party user's address. If the third-party user needs to use the blockchain mirror, they initiate a request through the blockchain platform. The platform assesses the user's rights, and once the platform confirms the user's rights, it retrieves the relevant blockchain mirror from the artifact repository and sends it to the third-party user's address for use.

[0065] The above-described solution provided in the embodiments of this application can be effectively implemented using blockchain technology, achieving distributed, decentralized, and trustworthy distribution, trading, and use of software image resources, and giving the data advantages such as immutability, full traceability, collective maintenance, and transparency.

[0066] By using non-fungible tokens (NFS) for container images, the image resources are put on the blockchain, making them immutable. Software images are mapped to digital assets on the blockchain, and the characteristics of container (Docker) image hash values ​​and the metadata characteristics of NFS tokens are used for binding. This effectively ensures the security and uniqueness of container images on the blockchain, guaranteeing the immutability of software image resources and preventing the platform from being infected with malware or cracked. Simultaneously, by utilizing the characteristics of NFS tokens and blockchain, the credibility of the images is guaranteed, preventing software piracy and effectively protecting software copyright.

[0067] This application also provides a non-volatile storage medium, which includes a stored program, wherein the program controls the device where the non-volatile storage medium is located to execute the above-mentioned image resource processing method during runtime.

[0068] The aforementioned non-volatile storage medium is used to store a program that performs the following functions: receiving a request message from a target account for a token to invoke an image resource in a resource management container, wherein the resource management container is used to store at least the issuer information of the image resource; upon triggering the request message, obtaining the target account's permissions, and if the target account has the permission to invoke the image resource, determining that the target account is allowed to operate on the image resource.

[0069] This application embodiment also provides a processor for running a program stored in a memory, wherein the program executes the above-described processing method for the image resources during runtime.

[0070] The processor described above is used to run a program that performs the following functions: receiving a request message from a target account for a token to invoke an image resource in a resource management container, wherein the resource management container is used to store at least the issuer information of the image resource; upon triggering the request message, obtaining the target account's permissions, and if the target account has the permission to invoke the image resource, determining that the target account is allowed to operate on the image resource.

[0071] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0072] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0073] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0074] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0075] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0076] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing mirrored resources, characterized in that, include: Receive a request message from a target account for a token of an image resource to invoke a resource management container, wherein the resource management container is used to store at least the issuer information of the image resource; Upon triggering the request message, the permissions of the target account are obtained, and if the target account has the permission to access the image resource, it is determined that the target account is allowed to operate on the image resource; The token of the mirror resource is determined by the following method: calculating the hash value of the mirror resource and storing the mirror resource in the first database of the blockchain; determining the token based on the name of the mirror resource, the hash value, and the issuer information, wherein the token is a non-fungible token, and the metadata of the non-fungible token includes the hash value of the mirror resource, the mirror name, and the digital identity of the issuer; Whether the target account has the right to access the mirrored resource is determined by the following method: requesting the issuer to obtain the token and sending a payment message to the target account; after the target account pays the blockchain transaction fee, transferring the token to the target account's address; inputting the token's ID into a function for ownership verification, and if the function outputs the target account's address, determining that the target account has ownership of the token and the right to access the mirrored resource.

2. The method according to claim 1, characterized in that, Obtaining permissions for the target account includes: Obtain a first identifier of the mirror resource pre-stored on the blockchain platform, and determine a second identifier of the mirror resource obtained from the target account, wherein the first identifier includes: a hash value determined at least based on the mirror resource and the issuer information of the mirror resource; If the first identifier and the second identifier are consistent, it is determined that the target account has the permission to access the image resource.

3. The method according to claim 2, characterized in that, Obtaining the mirror resource corresponding to the request message from the blockchain includes: determining the first smart contract of the blockchain, and obtaining the mirror resource corresponding to the first identifier through the first smart contract.

4. The method according to claim 3, characterized in that, The token for the mirrored resource is determined in the following way: Obtain a preset number of image resources for resource management containers, wherein the image resources include information about the resource management containers and information about the issuer; The token is determined based on the mirrored resource.

5. The method according to claim 1, characterized in that, Before receiving a request message from the target account for a token used to invoke the image resource of the resource management container, the following is included: Receive a request message from the target account for obtaining the token, and determine the address of the target account; Determine the second and third smart contracts of the blockchain; A preset number of virtual resources are obtained through the second smart contract, wherein the preset number of virtual resources are stored in the address of the target account; After confirming the acquisition of the preset number of virtual resources, the third smart contract transmits the permission to call the image resources to the address of the target account.

6. A processing apparatus for mirrored resources, characterized in that, include: A receiving module is configured to receive a request message from a target account for a token used to invoke an image resource in a resource management container, wherein the resource management container is configured to store at least the issuer information of the image resource; The acquisition module is used to acquire the permissions of the target account upon triggering the request message, and, if the target account has the permission to call the mirror resource, determine that the target account is allowed to operate on the mirror resource. The token of the mirror resource is determined by the following method: calculating the hash value of the mirror resource and storing the mirror resource in the first database of the blockchain; determining the token based on the name of the mirror resource, the hash value, and the issuer information, wherein the token is a non-fungible token, and the metadata of the non-fungible token includes the hash value of the mirror resource, the mirror name, and the issuer's digital identity; whether the target account has the permission to call the mirror resource is determined by the following method: requesting the issuer to acquire the token and sending a payment message to the target account; after the target account pays the blockchain transaction fee, transferring the token to the address of the target account; inputting the ID of the token into a function for confirmation of rights, and if the function outputs the address of the target account, determining that the target account has ownership of the token and the permission to call the mirror resource.

7. The apparatus according to claim 6, characterized in that, The acquisition module is further configured to acquire a first identifier of the mirror resource pre-stored on the blockchain platform, and determine a second identifier of the mirror resource acquired from the blockchain, wherein the first identifier includes: a hash value determined at least based on the mirror resource and the issuer information of the mirror resource; if the first identifier and the second identifier are consistent, it is determined that the target account has the permission to call the mirror resource.

8. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device where the non-volatile storage medium is located to perform the image resource processing method according to any one of claims 1 to 5.

9. A processor, characterized in that, The processor is used to run a program stored in a memory, wherein the program executes the image resource processing method according to any one of claims 1 to 5 when it runs.

Images