Drive configuration method, device and equipment in blockchain platform and storage medium

Abstract

The application is suitable for the field of blockchain technology, and provides a driving configuration method and device in a blockchain platform, equipment and a storage medium, wherein the method comprises the following steps: determining driving dependencies of each to-be-created driver according to a received driving creation instruction, wherein the driving dependencies comprise custom dependencies and core dependencies; determining access addresses of target dependency packages required by the driving dependencies based on the driving dependencies and a pre-constructed dependency federation set in the blockchain platform; and writing the access addresses of the target dependency packages into driving configuration files respectively according to each to-be-created driver. The scheme realizes dependency sharing among multiple drivers in the driving configuration process, reduces the dependency between independently developed drivers and the repeated writing and subsequent repeated loading of configuration codes, and reduces the repetitive workload.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a driver configuration method, apparatus, device and storage medium in a blockchain platform. Background Technology

[0002] With the development of blockchain technology, various institutions have launched their own blockchain platforms. These platforms differ in architecture and technology, and the deployment, maintenance, and application access methods involved in various underlying blockchain technologies also vary.

[0003] In order to reduce user access and maintenance costs, the concept of drivers is gradually being introduced into blockchain platforms, which plugs in IT service resources and the underlying blockchain to enrich the functionality of the blockchain platform.

[0004] However, due to technological limitations, existing technologies can only initialize standard lifecycle functions and simple project architectures for driver applications. Dependencies and page code must be implemented by the developers themselves. When facing configuration requirements with multiple drivers, dependencies between independently developed drivers and repetitive code writing and loading become unavoidable, leading to a sharp increase in repetitive workload and a significant decrease in blockchain platform performance. Summary of the Invention

[0005] This application provides a driver configuration method, apparatus, device, and storage medium for a blockchain platform to address the problem in the prior art where, when facing configuration requirements for multiple drivers, dependencies between independently developed drivers and repetitive code writing and loading are unavoidable, leading to a sharp increase in repetitive workload and a sharp decline in the performance of the blockchain platform.

[0006] The first aspect of this application provides a driver configuration method in a blockchain platform, including:

[0007] Based on the received driver creation instructions, the driver dependencies for each driver to be created are determined. The driver dependencies include custom dependencies and core dependencies. The custom dependencies are common dependencies between each driver to be created and the blockchain platform, and the core dependencies are common dependencies between all drivers to be created and the blockchain platform.

[0008] Based on the driving dependency and the pre-built dependency federation set in the blockchain platform, the access address of the target dependency package required by the driving dependency is determined; wherein, the dependency federation set records the public dependency packages corresponding to different common dependencies and the access address of each public dependency package;

[0009] For each driver to be created, the access address of the target dependency package is written into the driver configuration file.

[0010] A second aspect of this application provides a driver configuration device in a blockchain platform, comprising:

[0011] The dependency determination module is used to determine the driver dependencies of each driver to be created based on the received driver creation instructions. The driver dependencies include custom dependencies and core dependencies. The custom dependencies are common dependencies between each driver to be created and the blockchain platform, and the core dependencies are common dependencies between all drivers to be created and the blockchain platform.

[0012] The address acquisition module is used to determine the access address of the target dependency package required by the driver dependency based on the driver dependency and the pre-built dependency federation set in the blockchain platform; wherein, the dependency federation set records the public dependency packages corresponding to different common dependencies and the access address of each public dependency package;

[0013] The configuration module is used to write the access address of the target dependency package into the driver configuration file for each driver to be created.

[0014] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in the first aspect.

[0015] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0016] The fifth aspect of this application provides a computer program product that, when run on a computer device, causes the computer device to perform the steps of the method described in the first aspect.

[0017] As can be seen from the above, in this embodiment of the application, by introducing the concepts of common dependencies between multiple drivers and the blockchain platform and a dependency federation set, the driver dependencies of each driver to be created are determined according to the received driver creation instructions. The driver dependencies include custom dependencies formed by the common dependencies between each driver to be created and the blockchain platform, and core dependencies formed by the common dependencies between all drivers to be created and the blockchain platform. Based on the aforementioned driver dependencies and the dependency federation set pre-built in the blockchain platform that records the public dependency packages and their access addresses corresponding to different common dependencies, the access address of the target dependency package required by the driver dependency is determined. Then, according to each driver to be created, the access address of the target dependency package is written into the driver configuration file respectively. In the driver configuration process, dependency sharing between multiple drivers is realized, reducing the duplication of dependency and configuration code between independently developed drivers and subsequent duplication of loading, reducing repetitive workload, and ensuring the performance stability of the blockchain platform. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This application provides a flowchart of a driver configuration method in a blockchain platform. Figure 1 ;

[0020] Figure 2 This application provides a flowchart of a driver configuration method in a blockchain platform. Figure 2 ;

[0021] Figure 3 This is a structural diagram of a driver configuration device in a blockchain platform provided in an embodiment of this application;

[0022] Figure 4 This is a structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0025] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0026] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0027] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0028] It should be understood that the sequence number of each step in this embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0029] To illustrate the technical solution described in this application, specific embodiments are provided below.

[0030] See Figure 1 , Figure 1 This application provides a flowchart of a driver configuration method in a blockchain platform. Figure 1 The blockchain platform consists of a front-end and a back-end. The front-end acts as a client to interact with users, while the back-end acts as a server to connect to the blockchain system formed by multiple nodes. The back-end can respond to requests from the front-end to perform operations such as uploading, deleting, modifying, and querying transaction data on the blockchain system.

[0031] like Figure 1 As shown, the driver configuration method in this blockchain platform includes the following steps:

[0032] Step 101: Determine the driver dependencies for each driver to be created based on the received driver creation instructions.

[0033] The driver dependencies include custom dependencies and core dependencies.

[0034] Custom dependencies are common dependencies between each driver to be created and the blockchain platform; core dependencies are common dependencies between all drivers to be created and the blockchain platform.

[0035] For example, if there is a blockchain platform Center and drivers A, B, and C to be created, then the common dependency module Common of A, B, C, and Center will be abstracted to form the core dependency. The configuration items required for the core dependency can be initialized in the driver configuration file.

[0036] Furthermore, for driver A, besides sharing the common dependency module "Common" with drivers B, C, and Center, it also has other common dependencies, ModulesA (custom dependencies), with Center. Driver A can implement the Interface to write the configuration items for these custom dependencies, ModulesA, into its driver configuration file. Similarly, driver B shares a common dependency module "ModulesB" with Center, and driver C shares a common dependency module "ModulesC" with Center; the configuration items for these custom dependencies can also be written into their respective driver configuration files.

[0037] When creating a driver, you need to first determine the dependencies of the driver to be created. The driver to be created can be a front-end driver or a back-end driver.

[0038] In this embodiment of the application, the blockchain platform provides some public dependency packages. Different public dependency packages correspond to different common dependencies. These common dependencies specifically include the common dependencies between each setting driver and the blockchain platform, as well as all the common dependencies between the setting driver and the blockchain platform, so that the dependencies can be reused based on these public dependency packages when multiple drivers are created synchronously.

[0039] Optionally, the public dependency package provided in the blockchain platform includes common dependencies required for the front-end and back-end runtime of the blockchain platform, so as to enable the direct reuse of existing dependencies in the platform, improve processing efficiency and reduce load.

[0040] Specifically, each driver dependency to be created contains two parts. One part consists of the same dependencies between all the dependencies required by the driver to be created and the dependencies provided by the blockchain platform. These same dependencies form the core dependencies mentioned above. The other part consists of custom dependencies, which are the same dependencies between the dependencies required by each driver to be created and the dependencies provided by the blockchain platform.

[0041] This custom dependency can be configured by the user based on their driver creation requirements. Users can configure the dependencies for each driver to be created, matching their specific needs, based on the driver to be created and the dependencies provided by the blockchain platform.

[0042] Alternatively, users can write their own dependencies that can be reused on the blockchain platform based on the requirements of the driver creation. These self-written dependencies can be uploaded to the blockchain platform and become custom dependencies between each driver to be created and the blockchain platform.

[0043] In an optional implementation, determining the driver dependencies for each driver to be created based on the received driver creation instructions includes:

[0044] The received driver creation instruction is parsed to obtain the information parameters of each driver to be created and the specified custom dependencies carried in the driver creation instruction;

[0045] Based on the information parameters of all the drivers to be created, match the driver project template.

[0046] The driver project template includes the driver configuration file, which contains built-in configuration items, and the configuration items configure the core dependencies.

[0047] This information parameter may include, for example, the driver's functional description parameters, the driver name, and the driver's dependency information.

[0048] The specified custom dependencies can be selected by the user from the dependencies provided by the blockchain platform, or they can be written by the user.

[0049] Here, obtaining the core dependencies requires template matching based on the information parameters of all drivers to be created. Based on the configuration items in the matched templates, the core dependencies that correspond to the current multiple drivers to be created are determined.

[0050] Furthermore, after matching the driver project template based on all the information parameters of the drivers to be created, the process also includes:

[0051] Add the custom dependency corresponding to each driver to be created to the configuration item.

[0052] In this embodiment, since the custom dependencies corresponding to each driver to be created can be selected and set or can be programmed independently, after matching the driver project template based on the information parameters of all drivers to be created, the custom dependencies need to be added to the configuration items in the driver configuration file included in the template. This ensures that in subsequent processing, the access addresses of the target dependency packages corresponding to the core dependencies and the target dependency packages corresponding to the custom dependencies can be effectively written to the driver configuration file respectively.

[0053] Step 102: Based on the driver dependency and the pre-built dependency federation set in the blockchain platform, determine the access address of the target dependency package required by the driver dependency.

[0054] The dependency federation set records the public dependency packages corresponding to the different common dependencies and the access address of each public dependency package.

[0055] The dependency federation set records public dependency packages, including dependency packages corresponding to custom dependencies and dependency packages corresponding to core dependencies, as well as the access address of each dependency package.

[0056] In an optional implementation, before determining the driver dependencies for each driver to be created based on the received driver creation instructions, a dependency federation set needs to be generated in advance. The specific processing steps include:

[0057] Read the dependency array from the platform configuration file of the blockchain platform. The dependency array contains predefined global variables and public dependency data in the blockchain platform.

[0058] The public dependency data is packaged to obtain the public dependency package, and the public dependency package is stored in the access address corresponding to the global variable;

[0059] The public dependency packages and the access addresses are recorded to obtain the dependency federation set.

[0060] In this process, a dependency federation strategy is proposed within the blockchain platform. The blockchain platform itself acts as the central hub of the dependency federation, responsible for writing, compiling, and packaging common dependencies. Multiple driver projects to be configured reuse these dependencies and code by adding configuration items to the driver configuration files, thus enabling the sharing of identical dependencies between different drivers.

[0061] In practical applications, the blockchain platform uses a config file. First, the blockchain platform reads the shared configuration from the config file. By reading the expose parameter (reusable components, code, etc. in the blockchain platform) and the sharedDependency parameter (provided dependency sharing), it parses and constructs the parameter data to generate a module collection ModuleMap, which is a dependency federation collection. Then, it reads the object with a type value of 'var' from the library (the global variable name exposed to the project), takes the name of the object as the global variable name, and publishes the ModuleMap and attaches it to this global variable.

[0062] The introduction of global variables allows for direct access to data at the access address when the access address is called subsequently.

[0063] In this context, public dependency data in the blockchain platform can contain parameter data corresponding to different dependencies. When packaging public dependency data, it can be packaged separately according to the public dependency, resulting in public dependency packages corresponding to different public dependencies. Ultimately, a dependency federation set containing multiple public dependency packages and their access addresses is generated, enabling the integration of reusable dependencies within the blockchain platform.

[0064] In a different implementation, the dependent federation set corresponds to a set access address.

[0065] Correspondingly, in the process of determining the access address of the target dependency package required by the driving dependency based on the driving dependency and the pre-built dependency federation set in the blockchain platform, the processing steps specifically include:

[0066] Access the dependent federation set based on the set access address;

[0067] Determine whether there exists a target dependency package in the public dependency package recorded in the dependency federation set, whose name corresponds to the driver dependency;

[0068] If the determination is yes, then the access address corresponding to the target dependency package is extracted from the dependency federation set.

[0069] This process allows you to directly find the target dependency package corresponding to the driver dependency from the dependency federation set, and then directly obtain its access address.

[0070] In contrast, if it is determined that there is no target dependency package with a name corresponding to the driver dependency in the public dependency package recorded in the dependency federation set, then it is considered that the current dependency federation set cannot provide dependency support.

[0071] To ensure successful driver creation under different circumstances, in this case, it is necessary to obtain the pre-written dependency package that matches the driver dependency from the pre-written dependency set based on the independent dependency access address; use the pre-written dependency package as the target dependency package required by the driver dependency and obtain the access address of the pre-written dependency package.

[0072] Here, the independent dependency access address refers to the access address corresponding to the pre-written dependency set. Specifically, the independent dependency access address is a separately set data access address that is different from the set access address. Based on this independent dependency access address, the pre-written dependency set can be accessed.

[0073] A pre-written dependency set refers to a data collection containing multiple pre-written dependency packages. Based on the dependency information required by drivers for specific functions within a blockchain platform during creation and operation, dependency packages can be pre-written to obtain multiple pre-written dependency packages, forming a pre-written dependency set. This pre-written dependency set can be stored on other terminals, such as in the cloud or on data backup terminals, to meet driver creation needs in special circumstances.

[0074] Each pre-written dependency package in the pre-written dependency set has corresponding descriptive information, including the dependency package name, function, size, etc. When retrieving a pre-written dependency package matching the driver dependency from the pre-written dependency set, the name of the driver dependency can be matched with the names of each pre-written dependency package in the pre-written dependency set (i.e., ID matching). This allows for the selection of a pre-written dependency package corresponding to the driver dependency required by the driver to be created from an additional pre-configured dependency set when the current platform's dependency federation cannot provide dependency support. This enables the selection of such a package as the target dependency package for the driver dependency, obtaining its access address, and writing it into the driver configuration file for driver creation, ensuring successful configuration processing of the driver to be created under special driver creation requirements.

[0075] This strategy provides custom methods to support personalized operations for driver configuration without polluting the independent generation logic among multiple drivers.

[0076] Step 103: Write the access address of the target dependency package into the driver configuration file for each driver to be created.

[0077] The driver configuration file contains built-in configuration items, which include core dependencies and custom dependencies.

[0078] Therefore, when writing the access address of the target dependency package into the driver configuration file, it is necessary to write the access address of the target dependency package corresponding to the core dependency into the core dependency configuration item in the driver configuration file; and write the access address of the target dependency package corresponding to the custom dependency into the custom dependency configuration item in the driver configuration file.

[0079] If a target dependency package with a name corresponding to a driver dependency exists in the public dependency package recorded in the dependency federation set, the access address corresponding to the target dependency package will be extracted from the dependency federation set and written to the driver configuration file for each driver to be created.

[0080] If there is no target dependency package with a name corresponding to the driver dependency in the public dependency package that depends on the federated collection record, the pre-written dependency package is used as the target dependency package required by the driver dependency, and the access address of the obtained pre-written dependency package is written to the driver configuration file according to each driver to be created.

[0081] The above process can be applied to large-scale blockchain platforms, which decompose the large-scale blockchain platform into a main blockchain platform and many driver applications. When configuring multiple drivers, each driver is developed and deployed independently without interfering with each other. Furthermore, the different driver applications configured independently can share and reuse the same dependencies, avoiding a sharp increase in repetitive workload and a sharp decline in the performance of the blockchain platform.

[0082] In this embodiment, by introducing the concepts of common dependencies between multiple drivers and the blockchain platform and a dependency federation set, the driver dependencies of each driver to be created are determined according to the received driver creation instructions. These driver dependencies include custom dependencies formed by the common dependencies between each driver to be created and the blockchain platform, and core dependencies formed by the common dependencies between all drivers to be created and the blockchain platform. Based on the aforementioned driver dependencies and the dependency federation set pre-built in the blockchain platform that records public dependency packages and their access addresses corresponding to different common dependencies, the access address of the target dependency package required by the driver dependency is determined. Then, according to each driver to be created, the access address of the target dependency package is written into the driver configuration file. In the driver configuration process, dependency sharing between multiple drivers is realized, reducing the duplication of dependency and configuration code between independently developed drivers and subsequent duplication of loading, reducing repetitive workload, and ensuring the performance stability of the blockchain platform.

[0083] This application also provides different implementations of the driver configuration method in a blockchain platform.

[0084] See Figure 2 , Figure 2 This application provides a flowchart of a driver configuration method in a blockchain platform. Figure 2 .like Figure 2 As shown, a driver configuration method in a blockchain platform includes the following steps:

[0085] Step 201: Determine the driver dependencies for each driver to be created based on the received driver creation instructions.

[0086] The driver dependencies include custom dependencies and core dependencies.

[0087] Among them, custom dependencies are common dependencies between each driver to be created and the blockchain platform; core dependencies are common dependencies between all drivers to be created and the blockchain platform.

[0088] The implementation process of this step is the same as that of step 101 in the aforementioned embodiments, and will not be repeated here.

[0089] Step 202: Based on the driver dependency and the pre-built dependency federation set in the blockchain platform, determine the access address of the target dependency package required by the driver dependency.

[0090] The dependency federation set records the public dependency packages corresponding to the different common dependencies and the access address of each public dependency package.

[0091] The implementation process of this step is the same as that of step 102 in the aforementioned embodiments, and will not be repeated here.

[0092] Step 203: Write the access address of the target dependency package into the driver configuration file for each driver to be created.

[0093] The implementation process of this step is the same as that of step 103 in the aforementioned embodiments, and will not be repeated here.

[0094] Step 204: Based on the driver configuration file corresponding to each driver to be created, load the core dependencies and the custom dependencies through the target access address to generate each driver to be created.

[0095] In this embodiment of the application, to avoid potential configuration errors or duplicate configurations due to information asymmetry among developers and varying levels of understanding of the dependency federation configuration process, the implementation steps of steps 201 to 203 or 201 to 204 can be integrated into a driver factory class, Factory, based on the proposed dependency federation strategy. This Factory class provides a configuration interface.

[0096] After receiving the user's multi-driver creation instructions, the blockchain platform can call the driver factory class (Factory) to trigger the above processing steps, thus enabling one-click configuration or generation of driver application projects.

[0097] The above embodiments of this application provide a strategy that enables a blockchain platform to load public code and dependencies once and generate a driver project that reuses its public dependency modules with one click through configuration. This avoids the problems of repeated parsing, execution, and packaging of dependency modules, which increases the size and slows down loading. It also reduces the need for repeated writing and loading of dependency and configuration code between independently developed drivers, reduces repetitive workload, improves the driver configuration and data loading speed of the blockchain platform, and ensures the performance stability of the blockchain platform.

[0098] See Figure 3 , Figure 3 This is a structural diagram of a driver configuration device in a blockchain platform provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0099] The drive configuration device 300 in the blockchain platform includes:

[0100] The dependency determination module 301 is used to determine the driver dependencies of each driver to be created according to the received driver creation instruction. The driver dependencies include custom dependencies and core dependencies. The custom dependencies are common dependencies between each driver to be created and the blockchain platform, and the core dependencies are common dependencies between all drivers to be created and the blockchain platform.

[0101] Address acquisition module 302 is used to determine the access address of the target dependency package required by the driver dependency based on the driver dependency and the pre-built dependency federation set in the blockchain platform; wherein, the dependency federation set records the public dependency packages corresponding to different common dependencies and the access address of each public dependency package;

[0102] The configuration module 303 is used to write the access address of the target dependency package into the driver configuration file according to each driver to be created.

[0103] The dependency determination module 301 is specifically used for:

[0104] The received driver creation instruction is parsed to obtain the information parameters of each driver to be created and the specified custom dependencies carried in the driver creation instruction;

[0105] Based on the information parameters of all the drivers to be created, a driver project template is matched. The driver project template includes the driver configuration file, which contains built-in configuration items, and the configuration items configure the core dependencies.

[0106] The dependency determination module 301 is also specifically used for:

[0107] Add the custom dependency corresponding to each driver to be created to the configuration item.

[0108] The device also includes:

[0109] Build modules are used for:

[0110] Read the dependency array from the platform configuration file of the blockchain platform. The dependency array contains predefined global variables and public dependency data in the blockchain platform.

[0111] The public dependency data is packaged to obtain the public dependency package, and the public dependency package is stored in the access address corresponding to the global variable;

[0112] The public dependency packages and the access addresses are recorded to obtain the dependency federation set.

[0113] The dependent federation set corresponds to a set access address; the address acquisition module 302 is specifically used for:

[0114] Access the dependent federation set based on the set access address;

[0115] Determine whether there exists a target dependency package in the public dependency package recorded in the dependency federation set, whose name corresponds to the driver dependency;

[0116] If the determination is yes, then the access address corresponding to the target dependency package is extracted from the dependency federation set.

[0117] The address acquisition module 302 is also specifically used for:

[0118] If the determination is negative, then based on the independent dependency access address, retrieve the pre-written dependency package whose name corresponds to the driver dependency from the pre-written dependency set;

[0119] The pre-written dependency package is used as the target dependency package required by the driver dependency, and the access address of the pre-written dependency package is obtained.

[0120] The device also includes:

[0121] Generate modules for:

[0122] Based on the driver configuration file corresponding to each driver to be created, the core dependencies and the custom dependencies are loaded through the target access address to generate each driver to be created.

[0123] The driver configuration device in the blockchain platform provided in this application embodiment can implement the various processes of the above-described embodiment of the driver configuration method in the blockchain platform and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0124] Figure 4 This is a structural diagram of a computer device provided in an embodiment of this application. As shown in the figure, the computer device 4 of this embodiment includes: at least one processor 40 ( Figure 4 (Only one is shown in the diagram), memory 41, and computer program 42 stored in said memory 41 and executable on said at least one processor 40, which, when executed, implements the steps in any of the above method embodiments.

[0125] The computer device 4 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 4 may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will understand that... Figure 4 This is merely an example of computer device 4 and does not constitute a limitation on computer device 4. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0126] The processor 40 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0127] The memory 41 can be an internal storage unit of the computer device 4, such as a hard disk or memory of the computer device 4. The memory 41 can also be an external storage device of the computer device 4, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the computer device 4. Furthermore, the memory 41 can include both internal and external storage units of the computer device 4. The memory 41 is used to store the computer program and other programs and data required by the computer device. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0128] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0129] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0130] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0131] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only 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 or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0132] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0133] 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.

[0134] If the integrated module / 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0135] The methods described in this application can be implemented in whole or in part by a computer program product. When the computer program product is run on a computer device, the computer device executes the steps in the various method embodiments described above.

[0136] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A driver configuration method in a blockchain platform, characterized in that, include: Based on the received driver creation instructions, determine the driver dependencies for each driver to be created, including: parsing the received driver creation instructions to obtain information parameters and specified custom dependencies for each driver to be created carried in the driver creation instructions; matching a driver project template based on the information parameters of all drivers to be created, wherein the driver project template includes the driver configuration file, the driver configuration file contains built-in configuration items, and the configuration items configure core dependencies; the driver dependencies include the custom dependencies and the core dependencies; the custom dependencies are common dependencies between each driver to be created and the blockchain platform, and the core dependencies are common dependencies between all drivers to be created and the blockchain platform; Based on the driving dependency and the pre-built dependency federation set in the blockchain platform, the access address of the target dependency package required by the driving dependency is determined; wherein, the dependency federation set records the public dependency packages corresponding to different common dependencies and the access address of each public dependency package; For each driver to be created, the access address of the target dependency package is written into the driver configuration file.

2. The method according to claim 1, characterized in that, After matching the driver project template based on the information parameters of all the drivers to be created, the process further includes: Add the custom dependency corresponding to each driver to be created to the configuration item.

3. The method according to claim 1, characterized in that, Before determining the driver dependencies for each driver to be created based on the received driver creation instructions, the process further includes: Read the dependency array from the platform configuration file of the blockchain platform. The dependency array contains predefined global variables and public dependency data in the blockchain platform. The public dependency data is packaged to obtain the public dependency package, and the public dependency package is stored in the access address corresponding to the global variable; The public dependency packages and the access addresses are recorded to obtain the dependency federation set.

4. The method according to claim 1, characterized in that, The dependency federation set corresponds to a set access address; determining the access address of the target dependency package required by the driver dependency item based on the driver dependency item and the pre-built dependency federation set in the blockchain platform includes: Access the dependent federation set based on the set access address; Determine whether there exists a target dependency package in the public dependency package recorded in the dependency federation set, whose name corresponds to the driver dependency; If the determination is yes, then the access address corresponding to the target dependency package is extracted from the dependency federation set.

5. The method according to claim 4, characterized in that, After determining whether a target dependency package with a name corresponding to the driver dependency exists in the public dependency package recorded in the dependency federation set, the method further includes: If the determination is negative, then based on the independent dependency access address, retrieve the pre-written dependency package whose name corresponds to the driver dependency from the pre-written dependency set; The pre-written dependency package is used as the target dependency package required by the driver dependency, and the access address of the pre-written dependency package is obtained.

6. The method according to claim 1, characterized in that, After writing the access address of the target dependency package into the driver configuration file for each driver to be created, the method further includes: Based on the driver configuration file corresponding to each driver to be created, the core dependencies and custom dependencies are loaded through the access address of the target dependency package to generate each driver to be created.

7. A driver configuration device in a blockchain platform, characterized in that, include: The dependency determination module is used to determine the driver dependencies of each driver to be created based on the received driver creation instructions. The driver dependencies include custom dependencies and core dependencies. The custom dependencies are the common dependencies between each driver to be created and the blockchain platform, and the core dependencies are the common dependencies between all drivers to be created and the blockchain platform. The address acquisition module is used to determine the access address of the target dependency package required by the driver dependency based on the driver dependency and the pre-built dependency federation set in the blockchain platform; wherein, the dependency federation set records the public dependency packages corresponding to different common dependencies and the access address of each public dependency package; The configuration module is used to write the access address of the target dependency package into the driver configuration file according to each driver to be created; The dependency determination module is specifically used to parse the received driver creation instruction to obtain the information parameters of each driver to be created and the specified custom dependencies carried in the driver creation instruction; based on the information parameters of all the drivers to be created, it matches the driver project template, which includes the driver configuration file, which has built-in configuration items, and the configuration items configure core dependencies.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

Images