Block chain contract processing method and device, equipment and storage medium
By mounting persistent storage resources on multiple preset container groups and scheduling smart contract read requests based on preset scheduling strategies, the problem of difficulty in synchronizing smart contracts between multiple cloud instances is solved, and cross-container group synchronization and consistency of smart contracts is achieved, reducing development costs.
Patent Information
- Application Number
- CN202311566326.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-11-21
- Publication Date
- 2025-05-23
Smart Images

Figure CN120029723A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of blockchain technology, and specifically relates to a blockchain contract processing method, device, equipment and storage medium. Background Art
[0002] With the continuous development and maturity of blockchain technology, smart contracts on the blockchain have increasingly broad application scenarios, which also puts higher requirements on the development of smart contracts and the security of their codes.
[0003] In the related art, a local integrated development environment (IDE) is usually used for smart contract development. However, this smart contract development method requires the IDE to be downloaded locally, which will occupy a large amount of local resources and increase the cost of developing smart contracts for terminal objects.
[0004] At present, there are also some solutions that use the Software as a Service (SaaS) layer on the cloud to implement the blockchain integrated development environment. The terminal object uses the cloud blockchain integrated development environment to edit and simulate the debugging of the contract online. Since the service runs in the cloud cluster, this avoids the cumbersome integrated development environment installation process and the occupation of local resources. Moreover, the simulated contract debugging will not actually be on the chain, so there will be no billing for calling smart contracts. This solution greatly reduces the development cost of smart contracts. However, when using the cloud blockchain integrated development environment for smart contract development, the developed smart contract is usually saved on the cloud instance where the smart contract is developed or on the local disk. If it is saved on the cloud instance where the smart contract is developed, it is impossible to synchronize the smart contract between multiple cloud instances, and if it is saved on the local disk, it will occupy local resources and increase the development cost of the smart contract. Summary of the invention
[0005] In order to solve the above technical problems, the present application provides a blockchain contract processing method, device, equipment and storage medium.
[0006] On the one hand, an embodiment of the present application provides a blockchain contract processing method, the method comprising:
[0007] Receive a read request for a target smart contract; the read request carries storage information of the target smart contract; the storage information is used to indicate the storage location of the target smart contract in a preset storage resource;
[0008] Determine a first target container group in at least two preset container groups providing stateless services based on a first preset scheduling strategy; mount the preset storage resource on the at least two preset container groups through a persistent storage declaration;
[0009] dispatching the read request to the first target container group;
[0010] The shared storage service is called based on the first target container group, and the target smart contract is obtained from the location indicated by the storage information in the preset storage resource.
[0011] On the other hand, the embodiment of the present application also provides a blockchain contract processing device, the device comprising:
[0012] A read request receiving module, used to receive a read request of a target smart contract; the read request carries storage information of the target smart contract; the storage information is used to indicate the storage location of the target smart contract in a preset storage resource;
[0013] A first target container group determination module is used to determine a first target container group in at least two preset container groups providing stateless services based on a first preset scheduling strategy; the preset storage resource is mounted on the at least two preset container groups through a persistent storage declaration;
[0014] A read request scheduling module, configured to schedule the read request to the first target container group;
[0015] The target smart contract acquisition module is used to call the shared storage service based on the first target container group, and obtain the target smart contract from the location indicated by the storage information in the preset storage resource.
[0016] On the other hand, an embodiment of the present application also provides an electronic device for blockchain contract processing, the electronic device comprising a processor and a memory, the memory storing at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by the processor to implement the blockchain contract processing method as described above.
[0017] On the other hand, an embodiment of the present application also provides a computer-readable storage medium, in which at least one instruction or at least one program is stored, and the at least one instruction or the at least one program is loaded and executed by a processor to implement the blockchain contract processing method as described above.
[0018] On the other hand, an embodiment of the present application also provides a computer program product, which, when executed by a processor, implements the blockchain contract processing method as described above.
[0019] The blockchain contract processing method, device, electronic device and storage medium proposed in the embodiment of the present application use a persistent storage declaration to mount preset storage resources on at least two preset container groups. After receiving a read request for the target smart contract, the first target container group can be determined based on the first preset scheduling strategy in at least two preset container groups that provide stateless services. By scheduling the read request to the first target container group, the shared storage service can be called based on the first target container group to obtain the target smart contract from the location indicated by the storage information in the preset storage resource. Since the target smart contract is obtained from the preset storage resource, the synchronization of the target smart contract in different preset container groups is achieved, thereby ensuring the consistency of the target smart contracts obtained by different preset container groups, avoiding the occupation of local resources, and reducing the cost of smart contract development. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] In order to more clearly illustrate the technical solutions and advantages in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0021] Figure 1 It is a schematic diagram of an implementation environment of a blockchain contract processing method according to an exemplary embodiment.
[0022] Figure 2 It is a flowchart of a blockchain contract processing method according to an exemplary embodiment.
[0023] Figure 3 The diagram is a schematic diagram showing a preset container group mounting a preset storage resource according to an exemplary embodiment.
[0024] Figure 4 It is a schematic diagram of a processing flow of a smart contract according to an exemplary embodiment.
[0025] Figure 5 The present invention is a flowchart of storing a smart contract to be saved in a preset storage resource according to an exemplary embodiment.
[0026] Figure 6 It is a flowchart of a smart contract processing according to an exemplary embodiment.
[0027] Figure 7 It is a block diagram of a blockchain contract processing device according to an exemplary embodiment.
[0028] Figure 8It is a hardware structure block diagram of a server of a blockchain contract processing method provided according to an exemplary embodiment. DETAILED DESCRIPTION
[0029] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.
[0030] It should be noted that the terms "first", "second", etc. in the description and claims of the embodiments of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.
[0031] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.
[0032] In the embodiments of the present application, unless otherwise specified, "plurality" means two or more than two. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or server including a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0033] In order to make the purpose, technical solution and advantages disclosed in the embodiments of the present application more clearly understood, the embodiments of the present application are further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the embodiments of the present application and are not used to limit the embodiments of the present application.
[0034] The embodiments of the present application involve blockchain technology and cloud technology.
[0035] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.
[0036] The underlying blockchain platform can include processing modules such as terminal object management, basic services, smart contracts, and operational adjustments. Among them, the terminal object management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and the maintenance of the correspondence between the terminal object's real identity and the blockchain address (authority management), etc., and, under authorization, supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (common The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. The operation adjustment module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarm, network status detection, node equipment health status detection, etc.
[0037] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.
[0038] Cloud technology refers to a hosting technology that unifies hardware, software, network and other resources within a wide area network or local area network to achieve data computing, storage, processing and sharing. Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model. It can form a resource pool and be used on demand, which is flexible and convenient.
[0039] Cloud computing is a computing model that distributes computing tasks on a resource pool composed of a large number of computers, allowing various application systems to obtain computing power, storage space and information services as needed. The network that provides resources is called a "cloud". From the user's perspective, the resources in the "cloud" are infinitely scalable and can be obtained at any time, used on demand, expanded at any time, and paid for by use.
[0040] As a provider of basic cloud computing capabilities, a cloud computing resource pool (referred to as a cloud platform, generally referred to as an IaaS (Infrastructure as a Service) platform) will be established, and various types of virtual resources will be deployed in the resource pool for external customers to choose to use. The cloud computing resource pool mainly includes: computing devices (virtualized machines, including operating systems), storage devices, and network devices.
[0041] According to the logical function division, the PaaS (Platform as a Service) layer can be deployed on the IaaS (Infrastructure as a Service) layer, and the SaaS layer can be deployed on the PaaS layer, or SaaS can be deployed directly on IaaS. PaaS is a platform for software operation, such as databases, web containers, etc. SaaS is a variety of business software, such as web portals, SMS mass senders, etc. Generally speaking, SaaS and PaaS are upper layers relative to IaaS.
[0042] The blockchain contract processing method proposed in the embodiment of the present application can be applied to the scenario of developing smart contracts in the blockchain integrated development environment under the Kubernetes architecture. In order to facilitate the understanding of the technical solution described in the embodiment of the present application and the technical effects produced by it, the embodiment of the present application first explains the relevant professional terms:
[0043] Kubernetes: k8s cluster for short, a platform that supports cloud-native deployment, used to automate deployment, expansion and management of containerized applications. Kubernetes can make containerized application deployment and operation and maintenance more convenient.
[0044] Container: In the cloud blockchain integrated development environment, the container is used to carry the various service components of the integrated development environment and can provide smart contract development services or smart contract development interfaces.
[0045] Pod (container group): is the basic scheduling unit of the k8s cluster. Pod encapsulates application containers, storage resources, independent network IP, and policy options for managing and controlling container operation. In the blockchain integrated development environment, a Pod can contain one or more containers.
[0046] Cloud File Storage (CFS): used to provide shared file storage services. File storage uses the standard Network File System (NFS) access protocol to provide a shared data source for the server and supports elastic capacity and performance expansion.
[0047] In the related technology, using the local blockchain integrated development environment for smart contract development will occupy a large amount of local resources, while using the blockchain integrated development environment on the cloud for smart contract development will not be able to synchronize smart contracts between multiple cloud instances.
[0048] In view of this, the embodiments of the present application propose a blockchain contract processing method, device, electronic device and storage medium, which use persistent storage declarations to mount preset storage resources on at least two preset container groups. After receiving a read request for a target smart contract, a first target container group can be determined based on a first preset scheduling strategy in at least two preset container groups that provide stateless services. By scheduling the read request to the first target container group, a shared storage service can be called based on the first target container group to obtain the target smart contract from the location indicated by the storage information in the preset storage resource. Since the target smart contract is obtained from the preset storage resource, the synchronization of the target smart contract in different preset container groups is achieved, thereby ensuring the consistency of the target smart contracts obtained by different preset container groups, avoiding the occupation of local resources, and reducing the cost of smart contract development.
[0049] See also Figure 1 , Figure 1 FIG. 1 is a schematic diagram of an implementation environment of a blockchain contract processing method according to an exemplary embodiment. Figure 1 As shown, the implementation environment may include at least a terminal 01 and a server 02. The terminal 01 and the server 02 may be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitation thereto.
[0050] Specifically, the terminal 01 can be a client for developing smart contracts for a terminal object, and is used to send a read request for a target smart contract. Optionally, the terminal 01 can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart voice interaction device, a smart home appliance, a smart watch, a vehicle terminal, an aircraft, etc., but is not limited thereto.
[0051] Specifically, a container group management platform is deployed in the server 02, which is used to receive a read request for a target smart contract. And it is used to determine a first target container group in at least two preset container groups that provide stateless services based on a first preset scheduling strategy. And it is used to schedule the read request to the first target container group. And it is used to call a shared storage service based on the first target container group, and obtain the target smart contract from the location indicated by the storage information in the preset storage resource. Optionally, the server 02 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.
[0052] It should be noted that Figure 1 This is just an example. In other scenarios, other implementation environments may also be included.
[0053] Figure 2 is a flowchart of a blockchain contract processing method according to an exemplary embodiment. The method can be used Figure 1 In the implementation environment of the embodiment. This specification provides the method operation steps as described in the embodiment or flowchart, but may include more or fewer operation steps based on routine or non-creative work. The order of steps listed in the embodiment is only one way of executing the steps among many steps, and does not represent the only execution order. When the actual system or server product is executed, it can be executed in sequence or in parallel (for example, in a parallel processor or multi-threaded processing environment) according to the method shown in the embodiment or the drawings. Specifically, Figure 2 As shown, the method may include:
[0054] S101: Receive a read request for a target smart contract; the read request carries storage information of the target smart contract; the storage information is used to indicate a storage location of the target smart contract in a preset storage resource.
[0055] In the embodiment of the present application, the blockchain integrated development environment is implemented as a SaaS layer based on the cloud. Specifically, several preset container groups are created on a container group management platform (such as a k8s cluster) based on cloud technology, and the blockchain integrated development environment can run in the containers of these preset container groups. The terminal object logs in to the blockchain integrated development environment through the terminal, so that the blockchain integrated development environment can be used to implement the development of smart contracts. In general, in order to improve the scalability and reliability of the service and the concurrent processing capability of the integrated development environment, two or more preset container groups can be created when creating a preset container group in the container group management platform cluster. These preset container groups can provide stateless services, thereby ensuring the concurrent processing capability and disaster recovery performance of the service.
[0056] In the embodiment of the present application, the blockchain integrated development environment can provide a smart contract development interface through a web browser, and the terminal object can perform smart contract development, reading, testing, saving and other operations in the smart contract development interface.
[0057] When reading a smart contract, the terminal object can send a read request for the target smart contract to the container group management platform by triggering the read control of the target smart contract. The read request can be a request to read the entire content of the target smart contract, or it can be a request to read part of the content of the target smart contract. The embodiment of the present application does not impose too many restrictions on this. The read request can carry the storage information of the target smart contract, and the storage information indicates the storage location of the target smart contract. The container group management platform can obtain the target smart contract requested to be read by the terminal object from the storage location of the target smart contract based on the storage information. Optionally, the storage information can be the storage path information of the target smart contract, and the storage path information includes the root directory of the target smart contract and the subordinate directory where the target smart contract is located. In some embodiments, the storage information can also be the identification information of the target smart contract, and the container group management platform can determine the storage location of the target smart contract based on the identification information.
[0058] S103: Determine a first target container group in at least two preset container groups providing stateless services based on a first preset scheduling strategy; and mount preset storage resources on the at least two preset container groups through persistent storage declarations.
[0059] In an embodiment of the present application, two or more preset container groups may be provided in the container group management platform. During the development of smart contracts, the container group management platform often dispatches requests sent by terminal objects to various preset container groups for processing according to a certain scheduling strategy. During the development of smart contracts, if a smart contract is modified through a preset container group, since the file systems between the preset container groups are isolated from each other, other preset container groups in the container group management platform cannot obtain the modified content of the smart contract, which will cause the problem of inconsistent reading of smart contracts.
[0060] In order to enable the developed smart contracts to be shared among multiple preset container groups, the same preset storage resource can be mounted on multiple preset container groups. Specifically, when mounting the preset storage resource, the preset storage resource can be obtained first. Then create a persistent storage declaration, and establish a mapping relationship between the persistent storage declaration and the preset storage resource. In response to the creation instruction of the preset container group, the container group management platform can mount the preset storage resource on the storage volume directory of the preset container group based on the persistent storage declaration. By mounting the preset storage resources on multiple preset container groups, smart contracts can be shared among multiple preset container groups, thereby ensuring the consistency of the smart contracts processed during the smart contract development process and improving the development efficiency of smart contracts.
[0061] In the embodiment of the present application, the preset storage resource is the storage resource provided in the container group management platform cluster. In the k8s cluster, the preset storage resource can be a persistent volume (PersistentVolume, PV). A persistent volume is a piece of storage in the cluster, which can be prepared in advance by the cluster administrator, or dynamically prepared using a storage class (Storage Class). A persistent storage claim (PersistentVolumeClaim, PVC) is used to apply for storage resources. The persistent storage claim defines the information of the storage resources applied for, such as resource size, access mode, etc. After creating the persistent storage claim, the cluster will select a persistent volume that meets the requirements of the persistent storage claim from the existing persistent volumes according to the request for storage resources (storage space and access mode) of the persistent storage claim, and then bind the persistent volume that meets the requirements to the persistent storage claim. Finally, the preset container group can declare a persistent storage claim when mounting the volume, so that the persistent volume can be obtained according to the mapping relationship established between the persistent storage claim and the persistent volume, and then the underlying storage resources can be obtained.
[0062] In actual applications, Pod mounting a persistent volume actually mounts the file storage instance bound to the persistent volume. Figure 3 FIG. 1 is a schematic diagram showing a preset container group mounting a preset storage resource according to an exemplary embodiment. Figure 3As shown, when implementing the preset container group to mount the preset storage resource, you can first create a file storage instance. When creating a file storage instance, allocate a remote disk of a specified size to the file storage instance, such as 1T space. Then you can create a persistent volume to bind the created file storage instance, and specify the storage class (storageClass) of the persistent volume. Next, create a persistent storage declaration. When creating a persistent storage declaration, you need to set the resource size and access mode (such as read-write or read-only, etc.) applied for the persistent storage declaration, and specify the same storage class (storageClass) as the persistent volume. In the k8s cluster, the cluster will bind the persistent volume and the persistent storage declaration of the same storage class. Finally, implement Pod mounting storage resources based on the persistent storage declaration. When creating a Pod, declare the created persistent storage declaration and the local directory of the Pod in the Pod's configuration file (such as deployment yaml) to mount the persistent volume resource to the local directory of the Pod. Through the above operations, the k8s cluster will automatically mount the file storage instance bound to the persistent volume to the directory specified in the Pod when creating the Pod.
[0063] By using a file storage instance to store smart contracts, smart contracts are saved in a remote network file system instead of the Pod's local file system. Since the network file system is essentially a disk, even if the Pod is destroyed and rebuilt, the smart contract is still stored in the remote network file system to ensure that the smart contract will not be deleted.
[0064] In addition, file storage instances can be mounted on multiple preset container groups at the same time, so smart contracts can be shared among multiple preset container groups. Figure 4 is a schematic diagram of a processing flow of a smart contract according to an exemplary embodiment. Figure 4 As shown, multiple preset container groups mount the same remote network file system, and smart contracts are stored in the network file system. When processing smart contracts, terminal objects will send processing requests to the container group management platform. A request scheduler is deployed in the container group management platform. After the terminal object sends a processing request to the container group management platform, the request scheduler will first schedule the processing request to a preset container group for processing according to the preset scheduling strategy. Since multiple preset container groups mount the same remote network file system, the synchronization of smart contracts between different preset container groups can be achieved, thereby ensuring the consistency of smart contract reading and writing by different preset container groups during the development of smart contracts.
[0065] In an embodiment of the present application, a request scheduler deployed in the container group management platform can schedule requests sent by terminal objects, thereby ensuring load balancing between multiple preset container groups and improving the concurrent processing capability of the blockchain integrated development environment.
[0066] In response to the read request of the target smart contract sent by the terminal object, the request scheduler will schedule it to a preset container group for processing according to the first preset scheduling strategy.
[0067] As an optional implementation, the request scheduler obtains the scheduling order of at least two preset container groups and the historical scheduling record of each preset container group, and then schedules at least two preset container groups providing stateless services based on the scheduling order and the historical scheduling record of each preset container group to obtain the first target container group. According to the scheduling order and historical scheduling record of the preset container group, the first target container group for processing the read request is determined, so that each preset container group can process the read request in turn, thereby ensuring the load balancing of each preset container group.
[0068] In some embodiments, the first preset scheduling strategy may also be other scheduling methods, such as priority scheduling method, optimal scheduling method, etc.
[0069] S105: Scheduling the read request to the first target container group.
[0070] In the embodiment of the present application, after determining the first target container group, the request scheduler schedules the read request to the first target container group for processing.
[0071] S107: Call the shared storage service based on the first target container group, and obtain the target smart contract from the location indicated by the storage information in the preset storage resource.
[0072] In the embodiment of the present application, after the first target container group receives the read request dispatched by the request scheduler, it will process the read request. Specifically, the first target container group can obtain the storage information of the target smart contract carried in the read request by parsing the read request, and then the first target container group obtains the target smart contract from the location indicated by the storage information in the preset storage resource by calling the shared storage service.
[0073] The shared storage service is a file storage service for the Network File System (NFS). The network file system may include a client and a server, wherein the client is set in a preset container group and the server is set in a container group management platform. Data transmission can be achieved between the client and the server of the network file system based on the transmission control protocol / internet protocol. By using the shared storage service, the preset container group can access the shared resources in the server of the remote network file system just like accessing a local directory.
[0074] In an embodiment of the present application, after the first target container group calls the shared storage service and obtains the target smart contract from the location indicated by the storage information in the preset storage resource, the first target container group can send the obtained target smart contract to the terminal object.
[0075] In some embodiments, in order to ensure the reading security of the smart contract, the first target container group may first encode the target smart contract when sending the target smart contract to the terminal object, and then send the encoding result to the terminal object. Specifically, the first target container group encodes the target smart contract according to a preset encoding method to obtain the target contract data. Optionally, the preset encoding method may be a character-based encoding method, such as a Unicode character list (Unicode), a variable length character encoding for Unicode (UTF-8), and a binary data representation based on 64 printable characters (Base64). After encoding the target smart contract to obtain the target contract data, the target contract data may be sent to the target terminal so that the target terminal decodes the target contract data to obtain the target smart contract. The decoding method for decoding the target contract data by the target terminal corresponds to the encoding method of the target smart contract. By encoding the target smart contract and then sending the encoded target contract data to the target terminal, the development security of the smart contract is guaranteed.
[0076] In practical applications, smart contracts usually consist of multiple parts, and different components may be stored in different folders. When the terminal object is developing a smart contract, it may want to read a part of the content in the target smart contract. Therefore, in order to facilitate the terminal object to find the content it wants to read, after receiving the read request, the first target container group parses the read request to obtain the storage information of the target smart contract carried in the read request, and then the first target container group obtains the hierarchical directory of the target smart contract from the location indicated by the storage information in the preset storage resource by calling the shared storage service, and then returns the hierarchical directory of the target smart contract to the terminal object. The hierarchical directory of the target smart contract includes the root directory and each subordinate directory of the target smart contract. After obtaining the hierarchical directory of the target smart contract, the terminal object can find the target subordinate directory to be read in each subordinate directory, and then send a read request of the target subordinate target to the first target container group. The first target container group obtains the target content in the target subordinate directory from the preset storage resource by calling the shared storage service.
[0077] In the embodiment of the present application, during the development of a smart contract, after the terminal object completes the writing of the smart contract code file in the smart contract development interface, the code file of the smart contract can be sent to the container group management platform for saving by triggering the save control in the smart contract development interface. The container group management platform can then store the code file of the smart contract in a preset storage resource.
[0078] Specifically, the container group management platform receives a save request for a smart contract. The save request carries the contract data to be saved and the save path information. The save path information is used to indicate the storage location of the contract data to be saved in the preset storage resource. Then the request scheduler in the container group management platform determines the second target container group in the container group cluster based on the second preset scheduling strategy. The request scheduler then schedules the save request to the second target container group, and finally calls the shared storage service based on the second target container group to store the contract data to be saved in the location indicated by the save path information in the preset storage resource. By sending a smart contract save request to the container group management platform, the smart contract to be saved is saved in the preset storage resource. Since the preset storage resource is mounted on multiple preset container groups, it is ensured that the smart contract to be saved is synchronized in multiple preset container groups.
[0079] In the above-mentioned process of saving the smart contract, for the read request of the target smart contract sent by the terminal object, the request scheduler will schedule it to a preset container group for processing according to the second preset scheduling strategy. Optionally, the second preset scheduling strategy can be priority scheduling, polling scheduling, etc. Optionally, the second preset scheduling strategy can be the same as the first preset scheduling strategy, or it can be different, and the embodiment of the present application does not impose too many restrictions on this.
[0080] In order to ensure the transmission security of smart contracts, when the terminal sends the smart contract to be saved to the container group management platform, it usually encodes the smart contract to be saved first, so as to obtain the contract data to be saved, and then sends the contract data to be saved to the container group management platform for saving. Correspondingly, when the scheduling request is scheduled to the second target container group, the second target container group will first decode the contract data to be saved, so as to obtain the smart contract to be saved, and then save the smart contract to be saved.
[0081] Specifically, the contract data to be saved is obtained by encoding the smart contract to be saved in a preset encoding method. When the container group management platform saves the contract data to be saved, it can first decode the contract data to be saved in a preset decoding method based on the second target container group to obtain the smart contract to be saved. The preset decoding method corresponds to the preset encoding method. Optionally, the preset encoding method can be a Unicode character list (Unicode), a variable length character encoding for Unicode (UTF-8), a binary data representation based on 64 printable characters (Base64), etc. Then, the shared storage service is called based on the second target container group to store the smart contract to be saved to the location indicated by the save path information in the preset storage resource. By encoding the smart contract to be saved to obtain the smart contract to be saved, the security of the smart contract to be saved during the transmission process can be ensured.
[0082] In an embodiment of the present application, after obtaining the smart contract to be saved, the second target container group stores the smart contract to be saved in the location indicated by the save path information in the preset storage resource by calling the shared storage service. Specifically, based on the storage service process in the second target container group, the client that calls the shared storage service sends the smart contract to be saved and the save path information to the server of the shared storage service. The client of the shared storage service, that is, the client of the network file system is set in the second target container group, and the server of the shared storage service, that is, the server of the network file system is used to read and write the preset storage resource. Based on the server of the shared storage service, the smart contract to be saved is stored in the location indicated by the save path information in the preset storage resource. By calling the shared storage service to save the smart contract to be saved in the preset storage resource, since the preset storage resource is mounted on multiple preset container groups, the smart contract can be shared between multiple preset container groups, ensuring the consistency of the smart contracts processed during the smart contract development process and improving the development efficiency of the smart contract.
[0083] When saving a smart contract to be saved, the save path information may indicate the specific save path of the smart contract to be saved, or it may be the mount path of a preset storage resource. Specifically, in the case where the smart contract to be saved is obtained by modifying an existing smart contract, since the corresponding storage path already exists in the preset storage resource, the save path information may be the storage path of the smart contract. In the case where the smart contract to be saved is a newly developed smart contract, since the smart contract to be saved does not have a corresponding storage path in the preset storage resource, the save path information may be the directory where the preset storage resource is mounted in the preset container group. After the second target container group receives the save path information, a storage directory corresponding to the smart contract to be saved may be created in the network file system through the shared storage service, and the smart contract to be saved may be saved in the storage directory.
[0084] Figure 5 is a schematic diagram of a process of storing a to-be-saved smart contract into a preset storage resource according to an exemplary embodiment. Figure 5 As shown, when the terminal object edits the smart contract on the smart contract development page and saves the edited content, it sends a save request to the container group management platform by triggering the call to the integrated development environment service contract save interface. The save request encapsulates the smart contract to be saved and the save path information. When encapsulating the save request, the terminal first encodes the smart contract to be saved to obtain the contract data to be saved, and encapsulates it with the save path information to obtain the save request, and then sends the save request to the container group management platform. After the container group management platform passes the request scheduler, the request scheduler can dispatch the save request to the second target container group in round-robin training according to load balancing. After receiving the save request, the process in the business container in the second target container group decodes the source file of the contract to be saved according to the preset decoding method, and writes it to the specified location according to the save path information. Since the save location indicated by the save path information is a remotely mounted file system, the action of writing the contract file is completed by the client of the shared storage service. The process transfers the source file of the smart contract to be saved to the client of the shared storage service, and the client of the shared storage service sends the source file and save path of the smart contract to be saved to the server of the shared storage service through a network link. The server of the shared storage service receives the source file and save path of the smart contract to be saved, and writes it to the disk corresponding to the preset storage resource. In the above process of saving the smart contract to be saved, the preset container group itself does not save the smart contract, so the service provided by the preset container group is a stateless service, which ensures that the preset container group has high concurrent processing capabilities and service scalability.
[0085] In an embodiment of the present application, by mounting the same preset storage resource on multiple preset container groups, the synchronization of smart contracts in different preset container groups is achieved, thereby ensuring the consistency of target smart contracts obtained by different preset container groups, avoiding occupying local resources, and reducing the cost of smart contract development. Figure 6 is a flowchart of a smart contract processing according to an exemplary embodiment. Figure 6As shown, after the terminal object modifies the content of smart contract A, it sends a save request to the container group management platform, and the request scheduler dispatches the save request to the first preset container group or the second preset container group for processing, so as to save the modified content to the folder corresponding to smart contract A in the file storage instance. Similarly, the terminal object sends a read request to read smart contract A to the container group management platform, and the request scheduler dispatches the read request to the first preset container group or the second preset container group for processing, so as to read the smart contract A stored in the file storage instance. In other words, the request command of the terminal object to operate the contract, regardless of whether the request scheduler dispatches the request command to the first preset container group or the second preset container group, the final operation of the smart contract file is the smart contract file mounted on the disk corresponding to the preset storage resource, so that the smart contract content requested by the terminal object will not be inconsistent. Moreover, since the smart contract files obtained by the terminal object from different preset container groups are the same file, there is no need to consider the synchronization problem of smart contract files. The results of multiple requests of the terminal object are all determined, and stateless services are realized at the same time. Moreover, horizontal expansion of preset container groups and reconstruction and destruction of preset container groups become simple and safe, and the maintenance cost of the service is greatly reduced. Through the above solution, the blockchain integrated development environment can be implemented as a stateless service on the cloud, and smart contract file storage can be realized, which greatly improves the service in terms of concurrency, expansion, and stability, and makes it possible to provide high-availability, high-concurrency backend services for terminal objects. At the same time, it also reduces the success of product operation and maintenance, greatly improving the competitiveness of the product.
[0086] The present application also provides a blockchain contract processing device. Figure 7 is a block diagram of a blockchain contract processing device according to an exemplary embodiment. Figure 7 As shown, the device may include at least:
[0087] The read request receiving module 201 is used to receive a read request of a target smart contract; the read request carries storage information of the target smart contract; the storage information is used to indicate the storage location of the target smart contract in a preset storage resource;
[0088] A first target container group determination module 203 is used to determine a first target container group in at least two preset container groups providing stateless services based on a first preset scheduling strategy; the preset storage resource is mounted on at least two preset container groups through a persistent storage declaration;
[0089] A read request scheduling module 205, configured to schedule the read request to the first target container group;
[0090] The target smart contract acquisition module 207 is used to call the shared storage service based on the first target container group, and acquire the target smart contract from the location indicated by the storage information in the preset storage resource.
[0091] In some optional embodiments, the device further comprises:
[0092] A preset storage resource acquisition module is used to acquire preset storage resources;
[0093] A persistent storage declaration creation module is used to create a persistent storage declaration and establish a mapping relationship between the persistent storage declaration and the preset storage resources;
[0094] The preset storage resource mounting module is used to mount the preset storage resource on the storage volume directory of the preset container group based on the persistent storage declaration in response to the creation instruction of the preset container group.
[0095] In some optional embodiments, the first target container group determination module includes:
[0096] A scheduling information acquisition submodule, used to obtain the scheduling order of at least two preset container groups and the historical scheduling record of each preset container group;
[0097] The first target container group determination submodule is used to perform scheduling processing on at least two preset container groups providing stateless services based on the scheduling order and the historical scheduling record of each preset container group to obtain the first target container group.
[0098] In some optional embodiments, the device further comprises:
[0099] A target contract data determination module, configured to encode the target smart contract according to a preset encoding method based on the first target container group to obtain target contract data;
[0100] The target contract data sending module is used to send the target contract data to the target terminal so that the target terminal decodes the target contract data to obtain the target smart contract.
[0101] In some optional embodiments, the device further comprises:
[0102] A save request receiving module, used to receive a save request of a smart contract; the save request carries the contract data to be saved and the save path information; the save path information is used to indicate the storage location of the contract data to be saved in the preset storage resource;
[0103] A second target container group determining module, configured to determine a second target container group in the container group cluster based on a second preset scheduling strategy;
[0104] A save request scheduling module, configured to schedule a save request to a second target container group;
[0105] A contract data to be saved storage module, configured to call a shared storage service based on the second target container group, and store the contract data to be saved at a position indicated by save path information in a preset storage resource.
[0106] In some alternative embodiments, the contract data to be saved is obtained by encoding a smart contract to be saved according to a preset encoding method; the contract data to be saved storage module includes:
[0107] A smart contract to be saved determination sub-module, configured to decode the contract data to be saved according to a preset decoding method based on the second target container group to obtain a smart contract to be saved; the preset decoding method corresponds to the preset encoding method;
[0108] A smart contract to be saved storage sub-module, configured to call a shared storage service based on the second target container group, and store the smart contract to be saved at a position indicated by save path information in a preset storage resource.
[0109] In some alternative embodiments, the smart contract to be saved storage sub-module includes:
[0110] A save information sending unit, configured to call a client of the shared storage service to send the smart contract to be saved and the save path information to a server of the shared storage service based on a storage service process in the second target container group; the client of the shared storage service is set in the second target container group, and the server of the shared storage service is used for reading and writing a preset storage resource;
[0111] A smart contract to be saved storage determination unit, configured to store the smart contract to be saved at a position indicated by save path information in a preset storage resource based on the server of the shared storage service.
[0112] It should be noted that the embodiments of the blockchain contract processing apparatus provided in the embodiments of the present application and the above embodiments of the blockchain contract processing method are based on the same inventive concept.
[0113] The embodiments of the present application further provide an electronic device for blockchain contract processing. The electronic device includes a processor and a memory. At least one instruction or at least one program segment is stored in the memory, and the at least one instruction or at least one program segment is loaded and executed by the processor to implement the blockchain contract processing method provided in any of the above embodiments.
[0114] An embodiment of the present application also provides a computer-readable storage medium, which can be set in a terminal to store at least one instruction or at least one program for implementing a blockchain contract processing method in a method embodiment, and the at least one instruction or at least one program is loaded and executed by a processor to implement the blockchain contract processing method provided in the above method embodiment.
[0115] Optionally, in the embodiment of this specification, the storage medium may be located in at least one of the multiple network servers of the computer network. Optionally, in this embodiment, the above storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.
[0116] The memory of the embodiment of this specification can be used to store software programs and modules, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, applications required for functions, etc.; the data storage area may store data created according to the use of the device, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.
[0117] The embodiment of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the blockchain contract processing method provided by the above method embodiment.
[0118] The method embodiments provided in the embodiments of the present application can be executed in a terminal, a computer terminal, a server or a similar computing device. Taking running on a server as an example, Figure 8 1 is a hardware structure diagram of a server of a blockchain contract processing method provided according to an exemplary embodiment. Figure 8As shown, the server 300 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 310 (the central processing unit 310 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 330 for storing data, and one or more storage media 320 (such as one or more mass storage devices) for storing application programs 323 or data 322. Among them, the memory 330 and the storage medium 320 can be short-term storage or permanent storage. The program stored in the storage medium 320 may include one or more modules, each of which may include a series of instruction operations on the server. Furthermore, the central processing unit 310 can be configured to communicate with the storage medium 320 and execute a series of instruction operations in the storage medium 320 on the server 300. The server 300 may also include one or more power supplies 360, one or more wired or wireless network interfaces 350, one or more input and output interfaces 340, and / or one or more operating systems 321, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.
[0119] The input / output interface 340 may be used to receive or send data via a network. The specific example of the network may include a wireless network provided by a communication provider of the server 300. In one example, the input / output interface 340 includes a network adapter (Network Interface Controller, NIC), which may be connected to other network devices via a base station so as to communicate with the Internet. In one example, the input / output interface 340 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0120] It can be understood by those skilled in the art that Figure 8 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 8 More or fewer components as shown, or with Figure 8 Different configurations are shown.
[0121] It should be noted that the above-mentioned sequence of the embodiments of the present application is for description only and does not represent the advantages and disadvantages of the embodiments. The above-mentioned specific embodiments of this specification are described. Other embodiments are within the scope of the attached claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0122] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and server embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.
[0123] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.
[0124] The above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.
Claims
1. A blockchain contract processing method, It is characterized in that The method comprises: Receive a read request for a target smart contract; the read request carries storage information of the target smart contract; the storage information is used to indicate a storage location of the target smart contract in a preset storage resource; Determine a first target container group in at least two preset container groups providing stateless services based on a first preset scheduling strategy; the preset storage resource is mounted on at least two of the preset container groups through a persistent storage declaration; dispatching the read request to the first target container group; The shared storage service is called based on the first target container group, and the target smart contract is obtained from the location indicated by the storage information in the preset storage resource.
2. The method according to claim 1, It is characterized in that Before receiving the read request of the target smart contract, the method further includes: Acquire the preset storage resource; Creating a persistent storage declaration and establishing a mapping relationship between the persistent storage declaration and the preset storage resource; In response to the creation instruction of the preset container group, the preset storage resource is mounted on the storage volume directory of the preset container group based on the persistent storage declaration.
3. The method according to claim 1, It is characterized in that The determining, based on the first preset scheduling strategy, a first target container group from at least two preset container groups providing stateless services comprises: Obtaining a scheduling order of at least two of the preset container groups and a historical scheduling record of each of the preset container groups; Based on the scheduling sequence and the historical scheduling record of each of the preset container groups, scheduling processing is performed on at least two preset container groups providing stateless services to obtain the first target container group.
4. The method according to any one of claims 1 to 3, It is characterized in that After invoking the shared storage service based on the first target container group and acquiring the target smart contract from the location indicated by the storage information in the preset storage resource, the method further includes: Based on the first target container group, encoding the target smart contract according to a preset encoding method to obtain the target contract data; The target contract data is sent to a target terminal, so that the target terminal decodes the target contract data to obtain the target smart contract.
5. The method according to claim 1, It is characterized in that The method further comprises: Receive a save request for a smart contract; the save request carries the contract data to be saved and save path information; the save path information is used to indicate a storage location of the contract data to be saved in the preset storage resource; Determine a second target container group in the container group cluster based on a second preset scheduling strategy; dispatching the save request to the second target container group; The shared storage service is called based on the second target container group to store the contract data to be saved in the location indicated by the saving path information in the preset storage resource.
6. The method according to claim 5, It is characterized in that The contract data to be saved is obtained by encoding the smart contract to be saved according to a preset encoding method; the calling the shared storage service based on the second target container group to store the contract data to be saved to the location indicated by the saving path information in the preset storage resource includes: Based on the second target container group, the contract data to be saved is decoded according to a preset decoding method to obtain the smart contract to be saved; the preset decoding method corresponds to the preset encoding method; The shared storage service is called based on the second target container group to store the smart contract to be saved in the location indicated by the saving path information in the preset storage resource.
7. The method according to claim 6, It is characterized in that The calling the shared storage service based on the second target container group to store the smart contract to be saved to the location indicated by the saving path information in the preset storage resource includes: Based on the storage service process in the second target container group, the client that calls the shared storage service sends the smart contract to be saved and the saving path information to the server of the shared storage service; the client of the shared storage service is set in the second target container group, and the server of the shared storage service is used to read and write the preset storage resource; Based on the server of the shared storage service, the smart contract to be saved is stored in the location indicated by the saving path information in the preset storage resource.
8. A blockchain contract processing device, It is characterized in that The device comprises: A read request receiving module, used to receive a read request of a target smart contract; the read request carries storage information of the target smart contract; the storage information is used to indicate a storage location of the target smart contract in a preset storage resource; A first target container group determination module is used to determine a first target container group in at least two preset container groups providing stateless services based on a first preset scheduling strategy; the preset storage resource is mounted on at least two of the preset container groups through a persistent storage declaration; a read request scheduling module, configured to schedule the read request to the first target container group; The target smart contract acquisition module is used to call the shared storage service based on the first target container group, and acquire the target smart contract from the location indicated by the storage information in the preset storage resource.
9. An electronic device for blockchain contract processing, It is characterized in that The device includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded by the processor and executed by the blockchain contract processing method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, It is characterized in that The storage medium stores at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by the processor to implement the blockchain contract processing method as described in any one of claims 1 to 7.
11. A computer program product comprising a computer program, wherein, when the computer program is executed by a processor, it implements the blockchain contract processing method according to any one of claims 1-7.