CN116339689A

CN116339689A - Method and device for generating block chain driving package

Info

Publication number: CN116339689A
Application number: CN202211667451.1A
Authority: CN
Inventors: 谭锦志; 邱炜伟; 姚远庆; 李伟; 尚璇
Original assignee: Hangzhou Qulian Technology Co Ltd
Current assignee: Hangzhou Qulian Technology Co Ltd
Priority date: 2022-12-23
Filing date: 2022-12-23
Publication date: 2023-06-27

Abstract

The application is applicable to the technical field of block chains, and provides a method and a device for generating a block chain driving packet, wherein the method comprises the following steps: determining a keyword matrix according to the system keywords and the newly generated keywords, and generating a code file of a first driving page according to the keyword matrix; generating a first driving configuration file for installing a driving dependency file of the first driving page according to the dependency information of the keyword matrix; and generating a second driving configuration file for packaging the code files of the first driving page according to the code files of the first driving page, and generating a blockchain driving package according to the first driving configuration file and the second driving configuration file. The method and the device automatically generate the codes based on the scaffold system, can greatly improve the development efficiency, reduce the development cost, improve the quality and the readability of the codes generated by the natural language-like codes, and reduce the errors and the integration problems to be processed, thereby reducing the maintenance cost.

Description

Method and device for generating block chain driving package

Technical Field

The application belongs to the technical field of blockchain, and particularly relates to a method and a device for generating a blockchain driving packet.

Background

In developing using a blockchain platform, multiple driver packages need to be developed for different operating systems, different blockchain types, or blockchain versions. However, in the actual development process, the developer needs to change frequently according to the actual requirement, so that the development cost and maintenance cost of the driver are very huge, and because of the good or bad state of the developer when writing the code, the hidden danger of low executable degree and readability of the written code exists.

Disclosure of Invention

The embodiment of the application provides a method and a device for generating a blockchain driving package, which can solve the problems of low generation efficiency and quality of manually generated driving packages and high development and later maintenance cost.

In a first aspect, embodiments of the present application provide a method of generating a blockchain, including:

determining a keyword matrix according to at least one first keyword and a second keyword, wherein the first keyword is a system keyword, the second keyword is a keyword generated based on the at least one first keyword, and the second keyword inherits the dependency information of the first keyword;

generating a code file of a first driving page according to the keyword matrix, wherein the code file of the first driving page comprises a page description rendering file and a page style rendering file;

Generating a first driving configuration file according to the dependency information of the keyword matrix and the code file of the first driving page, wherein the first driving configuration file is used for installing the driving dependency file of the first driving page;

generating a second driving configuration file according to the code file of the first driving page, wherein the second driving configuration file is used for packaging the code file of the first driving page;

and generating a block chain driving package according to the first driving configuration file and the second driving configuration file.

In the embodiment of the application, a code file of a driving page is generated through a keyword, a first driving configuration file is generated according to the dependence of the keyword, a second driving configuration file is generated according to the code file of the driving page, and the dependence installation and the driving packaging are carried out according to the first driving configuration file and the second driving configuration file. Through the operation, the code generation efficiency of the driving package can be improved, and a developer only needs to redefine keywords according to actual demands, and does not need to spend a great deal of time to change the code content, so that the generation quality of the driving package is improved, and the cost of development and later maintenance is reduced.

In one possible implementation, the method further includes:

traversing the driving description file according to at least one first keyword to generate a first abstract syntax tree, wherein the first abstract syntax tree consists of a plurality of nodes;

obtaining at least one brother node which is positioned behind a first node and in front of a second node from the first abstract syntax tree, wherein the first node is used for generating a second keyword, and the second node corresponds to the custom keyword;

and taking the definition corresponding to the at least one brother node as the definition of the second key word.

That is, by generating a new key based on the key of the system, and the newly generated key inherits the dependency of the key of the system, it is facilitated that the newly generated key and the key of the system share the same data structure. In addition, the code generated according to the key words can enable the code to have high reusability and realize code modularization, so that the effect of improving the quality and the readability of the generated code can be achieved when the driving page code is generated according to the code and the code

In one possible implementation manner, the generating a code file for driving a page according to the keyword matrix includes:

Generating a second abstract syntax tree according to the keyword matrix;

acquiring a plurality of nodes from the second abstract syntax tree, wherein each node is used for generating a keyword for driving a page;

at least one brother node positioned behind a third node and in front of a fourth node in the plurality of nodes is used as description information of a first driving page, wherein the third node is used for generating a keyword of the first driving page, and the fourth node corresponds to a self-setting keyword;

and generating a code file of the first driving page according to the third node and the at least one brother node.

That is, the code file of the driving page is automatically generated through the keyword matrix, and when a new driving page is developed according to actual requirements, the code file of the new driving page can be generated through redefined keywords, so that the situation that the driving page elements are various and frequently adjusted due to missing and missing modification when the driving code is manually modified is avoided, and the cost of development and later maintenance is reduced.

In one possible implementation, the generating a code file that drives a page includes: and generating a code file of the first driving page by using a natural language.

That is, the code file of the driving page is generated by using the natural language-like, so that the code language can be unified, a developer can conveniently and quickly find errors in the code, and the code has good readability as a whole. In addition, the natural language-like language can generate code quickly, and the executable degree of the generated code is very high. Thus, code generated using natural-like language has extremely high readability and excellent quality.

In one possible implementation manner, the generating a first driving configuration file according to the dependency information of the keyword matrix and the code file of the first driving page includes:

generating an application dependency package field and a development environment dependency package field according to the dependency information of the keyword matrix;

acquiring page information of the first driving page according to the code file of the first driving page, wherein the page information of the first driving page comprises a name field, a version field and a description field;

and generating the first driving configuration file according to one or more of the application dependency package field, the development environment dependency package field, the name field, the version field and the description field. In one possible implementation manner, the generating a second driving configuration file according to the code file of the first driving page includes:

Acquiring page information of the first driving page according to the code file of the first driving page, wherein the page information of the first driving page comprises one or more of the following information: project name, version information, page style, page description, interface information and rights information;

and generating a second driving configuration file according to the page information of the first driving page.

In one possible implementation, the second driver profile may also be used to interactively communicate with a back-end interface.

In one possible implementation manner, the generating a blockchain driving package according to the first driving configuration file and the second driving configuration file includes:

downloading a drive dependency file required by the first drive page according to the first drive configuration file;

compressing and packaging the code file of the first driving page according to the packaging mode defined in the second driving configuration file to obtain a compressed package of the first driving page;

and generating a block chain driving packet according to the compressed packet of the first driving page.

In a second aspect, an embodiment of the present application provides an apparatus for generating a blockchain driving package, configured to perform the method in the first aspect or any possible implementation manner of the first aspect. In particular, the apparatus comprises means (or units) for performing the method of the first aspect or any possible implementation of the first aspect.

In a third aspect, an embodiment of the present application provides an apparatus for generating a blockchain drive package, including a memory, a processor, and a computer program stored in the memory and executable on the processor. In particular, the processor, when executing the computer program, implements the method of the first aspect or any possible implementation of the first aspect.

In a fourth aspect, the present embodiments provide a blockchain drive pack scaffolding system for performing the method for generating blockchain drive packs of any implementation of the first aspect of the present embodiments. Illustratively, the scaffolding system can quickly generate natural language-like compiled code from a driver description file written by a developer.

In a fifth aspect, embodiments of the present application provide a computer-readable storage medium comprising: the computer readable storage medium stores a computer program which, when executed by a processor, implements the steps of the method of the first aspect described above.

In a sixth aspect, embodiments of the present application provide a computer program product which, when run on a device that generates a blockchain drive package, causes the device that generates a blockchain drive package to perform the method of the first aspect or any of the possible implementations of the first aspect.

It will be appreciated that the advantages of the second to fifth aspects may be found in the relevant description of the first aspect, and are not described here again.

Compared with the prior art, the embodiment of the application has the beneficial effects that: according to the practical requirement, a piece of driving description file is written by using a natural language-like, the file can dynamically generate a blockchain driving scaffold, and a second driving configuration file is generated when a scaffold code and a driving page code are generated so as to conveniently and quickly communicate with a rear interface, so that all information in a current driving package is clearly browsed. Compared with the prior art, the method and the device for automatically generating the codes based on the scaffold system can greatly improve development efficiency and reduce development entrance threshold, cost and deployment time. And the natural language-like generated code improves the quality and readability of the code and reduces errors and integration problems to be handled, thereby reducing maintenance costs.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required for the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of an overall architecture of a solution for generating a blockchain driving packet according to an embodiment of the present application;

FIG. 2 is a flow chart of a method of generating a blockchain driver package provided by an embodiment of the present application;

FIG. 3 is a schematic flow chart of keyword generation provided in an embodiment of the present application;

FIG. 4 is a schematic diagram of a partial abstract syntax tree provided by an embodiment of the present application;

FIG. 5 is a schematic diagram of driver code generation provided by an embodiment of the present application;

FIG. 6 is a diagram of a drive page directory structure provided by an embodiment of the present application;

FIG. 7 is an exemplary summary diagram of the contents of a code generation phase provided by an embodiment of the present application;

FIG. 8 is an exemplary diagram of an info. Yml file provided by an embodiment of the present application;

FIG. 9 is a schematic view of a package code file directory according to an embodiment of the present application;

FIG. 10 is a schematic block diagram of a scaffold code file catalog provided in an embodiment of the present application;

FIG. 11 is a block diagram of an apparatus for generating a blockchain driver package provided by an embodiment of the present application;

fig. 12 is a schematic structural diagram of an apparatus for generating a blockchain driving packet according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.

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

In addition, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used merely to distinguish between descriptions and are not to be construed as indicating or implying relative importance.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

When using blockchain platform development, multiple driver packages need to be developed for different operating systems, different blockchain types, and blockchain versions. Newly generated drive packages are often obtained by copying the existing drive package code and modifying portions of the code content. The problem that the driver page of the manually developed driver package is always leaked, omitted and changed, the driver interface is not clear, and the readability of the driver code is not high.

In view of this, the present application proposes a method of generating a blockchain driver package, automatically generating a driver page code by a keyword, generating a driver dependency file according to dependency information of the keyword, and performing dependency installation and driver packaging according to the driver dependency file. Through the scheme, when the content of the actual driving description file is changed, the corresponding driving page code is changed, so that the condition that the manual modification is omitted or omitted is avoided. In addition, based on the codes generated by the natural language, the possibility that the codes cannot be executed due to local modification is reduced, the readability of the codes is improved, page information of all driving pages is summarized to a configuration file, and the problems of ambiguous details of driving interfaces and version change are avoided. The scheme can achieve the purposes of improving the generation efficiency and the generation quality of the block chain driving package and reducing the development and later maintenance cost.

For ease of understanding, some terms or concepts related to the embodiments of the present application are briefly described before describing the embodiments of the present application.

Scaffold system: in the field of software engineering, scaffolds can be interpreted as development tools, development frameworks that help developers use in the development process. The nature of the scaffolding system is that clients of the operating system, through command lines, can create projects and quickly generate rich configuration items. After the scaffold system is introduced, a developer does not need to build or write bottom software from scratch to configure tools and environment configuration to be used in the development process, thereby avoiding a large number of repeated code lines and multiplexing existing codes and functions.

Blockchain: a distributed billing system is formed based on a variety of techniques including cryptographic algorithms, consensus mechanisms, point-to-point transmission, mathematics, computer programming, and the like. Wherein the blockchain is divided into blocks and chains. The block includes a block header (including metadata) and a block body (including transaction data). The chain is formed by sequencing blocks according to time sequence and connecting hash values between a previous block and a subsequent block in series, and is not a real chain.

Abstract syntax tree (Abstract Syntax code, AST): a tree representation of an abstract syntax structure used to describe source code. Generally, an abstract syntax tree may be composed of a plurality of nodes. Wherein each node on the syntax tree represents a syntax structure of the source code. Abstract means that open source client scripting language (Js) code is structured into a data structure.

Dependency information: the dependency information of the node may be expressed as node. The node. Js dependency information includes dependency information such as application dependency information (dependencies information), development environment dependency information (devDependencies information), and peer dependency information (peer dependencies information). The application dependency information is mainly used for managing other dependencies which need to be introduced into the created project, and all dependencies in the application dependency information can be automatically introduced and inherited by all sub-projects by default; development environment dependency information includes dependencies required in the development process, e.g., some packages for unit testing; the companion dependency information refers to a host relationship between dependency packages, for example, if plug-in A is defined as a dependency package, plug-in B is not directly defined as a required dependency package, but dependency plug-in A necessarily requires indirect dependency plug-in B.

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. It will be apparent that the described embodiments are some, but not all, embodiments of the invention. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

An example is described below in connection with the specific scenario in fig. 1.

Fig. 1 is a schematic overall architecture diagram of a scheme for generating a blockchain driving packet according to an embodiment of the present application, and as shown in fig. 1, the embodiment of the present application is applied to a driving chain driving scaffold system. The scheme overall architecture of the embodiment of the application comprises a keyword generation stage, a code generation stage and a dependent installation and packaging stage.

Illustratively, the keyword generation stage includes three modules shown in FIG. 1, respectively: a system default key, a key verifier, and a key generator. The keyword checker is used for extracting sentences generating keywords. The key generator is used for generating a new key according to the default key of the system. After the newly generated keywords are obtained, a keyword matrix is formed according to the default keywords of the system and the newly generated keywords.

Illustratively, the code generation phase includes three modules shown in FIG. 1, respectively: the method comprises the steps of driving a page generator, driving a dependent file generator and a configuration file generator. The driving page generator is used for generating a code file of the driving page according to the keyword matrix. The driving dependency file generator is used for collecting all dependency information in the process of generating the driving page and generating the driving dependency file according to all the dependency information. The configuration file generator is used for generating a configuration file according to the page information, the project name, the version information, the interface information, the authority related information and the like of the driving page.

In the exemplary dependency installation and packaging stage, the driver dependency files generated in the code generation stage are installed one by one, each driver page is individually packaged into a folder according to the packaging mode defined in the configuration file, and all folders are summarized to obtain a complete driver package.

Illustratively, in one possible approach, the scaffolding system of embodiments of the present application may include a Yeoman scaffolding system, a Create-reaction-App scaffolding, and a Vue CLI scaffolding. The embodiments of the present application are not limited in this regard as to the choice of scaffolding system.

The function or role of the terms referred to in fig. 1 are briefly explained above. It should be noted that the nomenclature of the individual terms shown in fig. 1 is merely an exemplary description, and embodiments of the present application are not limited thereto. In fact, the naming of each term may be replaced by other names as long as the corresponding function is provided.

In addition, for convenience of description, hereinafter, the blockchain driving scaffolding system is simply referred to as a scaffolding system.

The process of generating a blockchain driving package according to embodiments of the present application will be described in detail below in conjunction with fig. 2 through 10.

FIG. 2 is a flow chart of a method for generating a blockchain driver package provided in an embodiment of the present application. It should be appreciated that the method of fig. 2 may be applied to the application scenario shown in fig. 1 by way of example and not limitation. As shown in fig. 2, the method comprises the steps of:

step S210: and determining a keyword matrix according to at least one first keyword and a second keyword, wherein the first keyword is a system keyword, the second keyword is a keyword generated based on the at least one first keyword, and the second keyword inherits the dependency information of the first keyword.

The terms "first keyword" and "second keyword" are introduced herein to distinguish different objects. The first key is used to refer broadly to the default key in the system. The second key is used to refer broadly to the new key generated using the default key.

Illustratively, generating the second key using the at least one first key takes the following form: the statement that generated the key is extracted by a key verifier, such as the key verifier shown in fig. 1, and then a new set of keys is generated using the default key in the system.

It should be understood that the number of keywords is not particularly limited in the embodiments of the present application.

Alternatively, the second key inherits the dependency information of the first key, which can be understood as: the newly generated key will inherit all the dependency information in the description to which the first key corresponds.

Illustratively, the dependency information of the first key includes: an existing React component library and a third party library introduced by default keywords of the system in the development process of the drive chain drive package.

Illustratively, the component libraries include one or more of the React 17.X component library, the Antd component library (i.e., the React UI component library), the React Dom component library, and the UI component library. Where the act refers to a Js library that renders data into hypertext markup language (Hyper Text Markup Language, HTML) views, which is commonly used to add dynamic functionality to HTML web pages, such as in response to various operations by a customer.

It should be understood that the component libraries of embodiments of the present application may also include other component libraries. The embodiments of the present application are not limited to this for the selection of component libraries.

Further, the second keyword inherits the dependency information of the first keyword, which means that the second keyword also depends on the component library associated with the first keyword.

For example, for the following text:

generating federated chain name components

The component being a text box

Maximum length of 20

Generate … …

Wherein, the "generate, component, yes, text box, maximum length, is" system default keyword ", the" generate … … component "is combined to be a defined special keyword capable of generating keywords, thus the" alliance chain name "becomes a new keyword (corresponding to the second keyword). After a new key, the text preceding the special key will become the definition of this new key (i.e. "federation chain name"). The newly generated key "federation chain name" will inherit all dependencies in the description at the same time. For example: the text box depends on antd@4.13.0 component library, react@17.x component library, act-dom@17.x component library and @ bias/ui@0.0.2 component library, and the newly generated keyword "alliance chain name" also depends on antd@4.13.0 component library, react@17.x component library, act-dom@17.x component library and @ bias/ui@0.0.2 component library.

In one possible manner, the keyword matrix refers to an ordered permutation and combination of the first keyword and the second keyword. Alternatively, a system default key may be combined with the newly generated key to obtain a key matrix.

S220: and generating a code file of a first driving page according to the keyword matrix, wherein the code file of the first driving page comprises a page description rendering file and a page style rendering file.

Illustratively, the page-describing rendering file is an index. Tsx file. The core in the index. Tsx file is a render function. The render function is a rendering function for adding corresponding rendering code according to the page description.

Illustratively, the page style rendering file is an index. The index, less file may store information about the size, color, and location of the components in the page.

Alternatively, the page description rendering file and the page style rendering file may be stored in a common folder (also referred to as public folder), which is a storage location for static files.

Illustratively, the code file of the first driver page includes a render function, a lifecycle function, and the like.

It should be appreciated that the code file of the first drive page may be used to refer broadly to the code file of a single drive page. In a specific implementation, a code file of a plurality of single drive pages can be generated, each single drive page can be packaged into a folder in a dependent installation stage, and all the folders are finally packaged into a complete drive.

It should also be understood that the foregoing is described by taking the code file of the first driving page as an example, and embodiments of the present application are not limited thereto. In fact, each driver page is a separate folder, and the code file of each driver page may include an index.

It should also be appreciated that the specific manner in which the first driver page code is generated is not specifically limited by the embodiments of the present application.

Alternatively, in one possible implementation, the code file of the first driver page may be generated using a natural language-like language.

Through the keyword matrix of step S210 and based on the scaffold system, codes similar to natural language can be rapidly generated, and the difficulty degree of coding the codes is reduced. And the generated corresponding codes are changed according to the change of the key words, so that the generated codes are more modularized and highly adaptive, the execution efficiency of the generated codes is improved, and the reliability of the codes is improved.

After the key matrix is generated, the dependency information of the key matrix can be automatically acquired so as to generate a first driving configuration file for use.

Collection is relied upon to facilitate obtaining which view layers have used the data when its attribute value changes, and sending update notifications to the view layers when the data changes.

Alternatively, in one possible implementation, all dependency information in generating the driver page is collected and a dependency list is composed.

Alternatively, in one possible implementation, a subscription model may be published through an event of a drive chain development platform, creating subscribers (dependencies, dep) to collect dependencies, delete dependencies, send messages to dependencies, etc., and deposit observer objects, and creating observer objects (also called watchers), which notify the observer objects when data changes, which in turn notify the view layer.

It should be understood that the foregoing description of the manner of collecting the dependency information is merely taken as an example, and the embodiment of the present application is not limited to a specific manner of obtaining the dependency information of the keyword matrix.

S230: and generating a first driving configuration file according to the dependency information of the keyword matrix and the code file of the first driving page, wherein the first driving configuration file is used for installing the driving dependency file of the first driving page.

Optionally, as a possible implementation manner, S230 includes:

generating an application dependency package field and a development environment dependency package field according to the dependency information of the keyword matrix; acquiring page information of the first driving page according to the code file of the first driving page, wherein the page information of the first driving page comprises a name field, a version field and a description field; and generating the first driving configuration file according to one or more of the application dependency package field, the development environment dependency package field, the name field, the version field and the description field.

Optionally, the description field includes a page style field (e.g., a field for information about the size, color, and location of components in the page), and a page description field.

Illustratively, all the dependency information (i.e., the dependency information of the keyword matrix) in the code file that generates the first driving page may be collected, and the first driving configuration file may be generated in combination with the page information (e.g., name field, version field, description field) of the first driving page.

Illustratively, the first drive profile is a package.

S240: and generating a second driving configuration file according to the code file of the first driving page, wherein the second driving configuration file is used for packaging the code file of the first driving page.

Optionally, as a possible implementation manner, S240 includes:

acquiring page information of the first driving page according to the code file of the first driving page, wherein the page information of the first driving page comprises one or more of the following information: project name, version information, page style, page description, interface information and rights information; and generating a second driving configuration file according to the page information of the first driving page, and generating the second driving configuration file.

For example, page information of the first driving page may be collected and summarized into the second driving configuration file, that is, according to the collected following information: project name, version information, interface information and authority information, and a second drive configuration file is generated.

Illustratively, the second drive profile is an info. Yml file. In the code generation stage, an info. Yml file may be generated according to item names, version information, interface information, rights information, and the like.

Optionally, the second driving configuration file includes information of the packaging mode. Wherein the packing pattern information defines a packing pattern of the driving page.

Illustratively, in the subsequent package packaging stage, each driving page may be packaged one by one according to the packaging mode defined in the info. Yml file, and then assembled into a complete compressed package.

Illustratively, in another possible implementation, the second driver configuration file may also be used to interactively communicate with an interface of the backend.

The page information of each driving page is summarized through the second driving configuration file, so that the information of the driving page can be conveniently and clearly browsed by a developer, and the information can be strongly communicated with a blockchain driving package development platform to quickly receive the information of the driving interface and the driving version change, and the problems of unclear and ambiguous driving interface are solved.

S250: and generating a block chain driving package according to the first driving configuration file and the second driving configuration file.

Illustratively, the drive dependency file is downloaded into a storage dependent folder (e.g., node_module folder) from the drive dependency file in the first drive configuration file. And then, packaging the driving pages one by one according to the packaging mode in the second driving configuration file.

It should be appreciated that the embodiment of the present application does not specifically limit the specific manner of packaging the code file of the first driving page.

Taking the code file of the first driver page as an example, the dependent installation of the driver package may be implemented by:

(1) Executing an "npm run install" command;

(2) The drive dependent file is downloaded into the node module folder.

It should be understood that the foregoing is described by way of example only, and embodiments of the present application are not limited thereto.

Taking the code file of the first driving page as an example, the packing of the code file of the first driving page may be achieved by:

(1) Executing an npm run build command;

(2) And compiling and packaging the code file of the first driving page into a designated folder.

It should be understood that the foregoing is described by way of example only, and embodiments of the present application are not limited thereto. The embodiment of the application does not specifically limit the specific manner of installing the driving dependency file of the first driving page.

In the embodiment of the application, the driving description file is written by using the natural language according to the requirements of clients, the file can dynamically generate the blockchain driving scaffold, and a second driving configuration file can be generated when the scaffold code and the driving page code are generated, so that the second driving configuration file can conveniently and quickly communicate with the back-end interface, and all information of the driving package can be clearly seen. Compared with the prior art, the method and the device automatically generate codes based on the scaffold system, can greatly improve development efficiency, and reduce development entrance threshold, cost and deployment time. And the natural language-like generated code improves the quality and readability of the code and reduces errors and integration problems to be handled, thereby reducing maintenance costs.

A specific method of generating the second keyword will be described below in conjunction with fig. 3. It should be understood that the method in fig. 3 is an example description of "the second keyword is a keyword generated based on the at least one first keyword" in the method of generating a blockchain driving package shown in fig. 2 by way of example and not limitation, and the embodiments of the present application are not intended to be limited to the specific scenario illustrated.

Optionally, as a possible embodiment, before step S210, the method further includes the following steps:

step S211: traversing the drive description file according to at least one first keyword to generate a first abstract syntax tree, wherein the first abstract syntax tree is composed of a plurality of nodes.

It is understood that the first abstract syntax tree comprises a plurality of levels of nodes. For example, a node of a certain level may be referred to as a parent node, and the next level of the parent node may include a plurality of child nodes.

Step S212: at least one sibling node positioned behind a first node and in front of a second node is obtained from the first abstract syntax tree, wherein the first node is used for generating a second keyword, and the second node corresponds to the custom keyword.

The first node is a node for generating a new key.

Illustratively, each sibling node corresponds to a first key.

Custom keywords refer to special keywords. Illustratively, a custom keyword is a specific keyword that specifies that the keyword can be generated well defined. For example, for text: "generate federation chain name component", defines "generate … component" as a custom key (or referred to as a special key).

Step S213: and taking the definition corresponding to the at least one brother node as the definition of the second key word.

For the convenience of understanding by those skilled in the art, the steps of fig. 3 will be described below with reference to the example of fig. 4. Fig. 4 is a schematic diagram of a partial abstract syntax tree provided in an embodiment of the present application.

It should be appreciated that a partial schematic diagram of the first abstract syntax tree is shown in fig. 4, and embodiments of the present application are not limited thereto.

Optionally, step S211 includes: according to the drive description file, a keyword checker reads the file line by line, extracts sentences, splits keywords according to the extracted sentences and according to the sentences, and generates a first abstract syntax tree.

As shown in FIG. 4, by way of example and not limitation, a partial abstract tree includes, from top to bottom, a first level node, a second level node, and a third level node. Each hierarchy has a plurality of nodes. For example, each node in the first hierarchy corresponds to a statement in the drive description file; the nodes in the second hierarchy correspond to keywords obtained by splitting the statement; the nodes in the third hierarchy correspond to keywords obtained by splitting the statement.

Referring to FIG. 4, for the first hierarchy, all read statements are arranged in order from left to right, including statements such as "generate coalition chain name component," "component is a text box," "maximum length is 20," "generate …" (note: here the statement "generate …," the "component" is omitted from the figure). For the second hierarchy, the keywords obtained by splitting the sentence are arranged in order from left to right: "generate", "alliance chain name", "component", "text box", "maximum length" and "20". For the third hierarchy, the keywords obtained by splitting the sentence are arranged in order from left to right: "federation chain name", "component", "yes", "text box", "yes" and "20".

Taking one branch in fig. 4 as an example, the parent-child relationship between the nodes of the hierarchy is illustrated, wherein the node corresponding to the "generate alliance chain name component" in the first hierarchy, and the child node is the node corresponding to the "generate" and the node corresponding to the "alliance chain name component" in the second hierarchy. The child nodes of the nodes corresponding to the 'alliance chain name component' in the second level are the nodes corresponding to the 'alliance chain name' and the nodes corresponding to the 'component' in the third level.

Illustratively, the "generate … component" can be defined as a custom key (i.e., a special key) that can generate the second key. The key verifier recognizes that the text "generate coalition chain name component" contains a "generate … component" and that the "generate component" is a system default key, thereby defining the "coalition chain name" as a newly generated key.

It should be understood that the custom keywords herein are merely exemplary, and that other manners of defining the custom keywords are possible. The embodiments of the present application are not limited in this regard.

It should also be understood that the first keyword herein is only exemplary, and that other definitions of the first keyword are possible. The embodiments of the present application are not limited in this regard.

It should also be understood that custom keywords may be named in other ways, such as special keywords, etc. The embodiments of the present application are not limited in this regard.

It should be understood that the first abstract syntax tree herein is only an exemplary description, and that other naming schemes are possible for the first abstract syntax tree. The embodiments of the present application are not limited in this regard.

Optionally, step S212 includes: the keyword checker traverses the first abstract syntax tree, continues traversing until a node corresponding to the custom keyword is identified again after the first node for generating the second keyword is identified, and at least one brother node between the first node and the second node is obtained.

Referring to fig. 4, in combination with the description in step S211, it is determined that "generate coalition chain name component" is a sentence that generates the second keyword, wherein "coalition chain name" is a newly generated keyword. The keyword verifier continues to traverse one by one, recognizing that the component is a text box, the maximum length is 20, the generation … and the like. Because the keyword verifier recognizes the custom keyword, it is determined that the node corresponding to the sentence "component is a text box" and "maximum length is 20" is a sibling node.

Still taking the abstract syntax tree shown in fig. 4 as an example, the known keyword verifier sequentially extracts sentences of "generate coalition chain name component", "component is text box", "maximum length is 20", "generate coalition chain version component", and the like, wherein "coalition chain name" and "coalition chain version" are newly generated keywords. Then, the "component is a text box", "maximum length is 20" is described as "alliance chain name". And, the key "federation chain name" inherits the dependency information in the description.

In summary, by generating a new keyword based on the system keyword, and inheriting the dependency of the system keyword by the newly generated keyword, the newly generated keyword and the system keyword can share the same data structure. In addition, the code generated according to the keywords can enable the code to have high reusability and realize code modularization, so that the quality and the readability of the generated code can be improved when the driving page code is generated according to the code and the code.

For ease of understanding by those skilled in the art, the method of generating a blockchain driving package is described below in connection with the specific example in fig. 5. It should be understood that the method in fig. 5 is an example of step S220 in the method of generating a blockchain driving package shown in fig. 2 by way of example and not limitation, and the embodiments of the present application are not intended to be limited to the specific scenario illustrated.

Optionally, as a possible embodiment, the generating the code file of the first driving page includes the following steps:

step S221: and generating a second abstract syntax tree according to the keyword matrix.

Step S222: and acquiring a plurality of nodes from the second abstract syntax tree, wherein each node is used for generating a keyword for driving the page.

Step S223: and taking at least one brother node positioned behind a third node and in front of a fourth node in the plurality of nodes as the description information of the first driving page, wherein the third node is used for generating a keyword of the first driving page, and the fourth node corresponds to the self-setting keyword.

Illustratively, each sibling corresponds to a first/second key.

Illustratively, self-setting keywords refer to keywords that combine to create a driver page. For example, for text: "generate coalition chain name component", set "generate … page" is a key to create a driver page from the set.

Step S224: and generating a code file of the first driving page according to the third node and the at least one brother node.

The following is a one-by-one explanation of the steps involved in fig. 5:

for step S221:

illustratively, in one possible implementation, the key verifier again reads the drive description file row by row and generates a second abstract syntax tree based on a key matrix of system default keys and new generated keys.

It should be understood that, for the selection of the key verifier and the generation of the second abstract syntax tree, reference may be made to the description at step S211, and for brevity, no further description is given here.

After expanding system keywords by traversing the driving description file in the earlier stage, generating a second abstract syntax tree according to ordered combination of default keywords and new keywords of the system, and sweeping the situation that part of keywords cannot be identified, so that the scaffold system cannot automatically generate codes for driving pages.

For step S222:

illustratively, the key verifier determines a plurality of nodes that generate the key that drives the page by identifying the self-setting key.

Illustratively, it is assumed that the keyword checker sequentially extracts statements such as "create coalition chain page, page contains coalition chain name, page contains coalition chain version, generate delete coalition chain page", etc., where developer definition "generate … page" is a self-set keyword of generate driving page. Aiming at the statement "create alliance chain page" and the statement "delete alliance chain page", the self-set keywords in the statement are removed, then "create alliance chain" and "delete alliance chain" are keywords which can generate driving pages, and the nodes corresponding to the keywords which can generate driving pages are determined.

It should be understood that the self-setting keywords herein are merely exemplary, and that other definitions of the self-setting keywords are possible. The embodiments of the present application are not limited in this regard.

It should be understood that the examples herein are merely for facilitating understanding of the technical solutions of the present application by those skilled in the art, and the embodiments of the present application are not limited thereto.

For step S223:

illustratively, in connection with the expression in step S222, "create federation chain" and "delete federation chain" are keywords that can generate a driver page. Where it is assumed that "create coalition chain" is a key to the first driven page, then "page contains coalition chain name, page contains coalition chain version" will be the page description of the driven page generated from the key "delete coalition chain".

For step S224:

illustratively, in one possible approach, the code file of the drive page is rendered and automatically generated from the keywords that generated the first drive page and the page description of the first drive page, and based on the scaffolding system.

Illustratively, the generated drive pages are stored in a page folder of the scaffold code file directory. Each drive page corresponds to an independent folder.

Illustratively, fig. 6 shows a schematic diagram of a driving page directory structure provided in an embodiment of the present application. In FIG. 6, the name of each individual driver page folder is defined by the key that generated the driver page. For example, "create coalition chain page" is a statement in the drive description file, where "create coalition chain" is a key to generate a drive page, and then the page name of the generated drive page is also "create coalition chain".

As shown in fig. 6, by way of example and not limitation, the directory structure of the drive page includes: creating a coalition chain folder, deleting the coalition chain folder, deleting a coalition chain link point folder, adding a coalition chain node folder, and configuring the coalition chain folder. It can be seen that the folder of each drive page includes an index. Tsx TypeScript file and an index. Less file.

It should be understood that the manner in which the code file that drives the page is generated is not particularly limited by the embodiments of the present application.

In summary, the keywords of the system and the newly generated keywords form the keyword matrix, and then the code file of the driving page is automatically generated by means of the scaffold system according to the keyword matrix, so that a great deal of time and effort for compiling codes by a developer are avoided, and the development and later maintenance cost of the driving package is reduced. In addition, the code file is generated by the quasi-natural language, so that the problem of poor code readability caused by changing developers during development is solved.

The process of how the driver page code is generated is described above. In addition to generating code that drives the page, other configuration files need to be generated. Referring to fig. 7, fig. 7 is an exemplary summary of the contents of the code generation phase. Fig. 7 is a schematic diagram of driver code generation provided in an embodiment of the present application.

Referring to fig. 7, according to the natural language description file, the scaffold system mainly completes three parts of contents in a code generation stage, namely, a code file for generating a driving page, a first driving configuration file (package. Json file) according to the code file and the dependency information, and a second driving configuration file (info. Yml file) according to the page information of the driving page.

It should be understood that the example in fig. 7 is merely an exemplary description and embodiments of the present application are not limited thereto.

Illustratively, in one possible implementation, the generating a first driver configuration file according to the dependency list and the code file of the first driver page includes:

generating an application dependency package field and a development environment dependency package field according to the dependency information;

The first driver configuration file is generated from the application dependent package field (also referred to as dependencies field), the development environment dependent package field (also referred to as dependencies field), and page information of a first driver page.

In one possible implementation, the application dependency package field is used to place dependencies that are needed in code runtime, and the development environment dependency package field is used to place compilation modules, packaging modules, testing modules, etc. that are needed in the local development process.

Illustratively, the package. Json file includes a dependencies field and a dependencies field. Optionally, the package. Json file further includes fields such as name, version, description, etc.

In addition, referring to fig. 8, fig. 8 shows an exemplary diagram of an info. Yml file of an embodiment of the present application. The info. Yml file is used to interactively communicate with the backend interface.

It should be understood that the info. Yml shown in FIG. 8 is merely an exemplary description and embodiments of the present application are not limited thereto.

Illustratively, the info. Yml file includes one or more of item naming, item description, version information, interface information, and rights-related information.

Illustratively, taking the first driving page as an example, page information of the first driving page is collected and summarized into the second driving configuration file.

Optionally, taking the page information of one driving page recorded in fig. 8 as an example, the collected page information includes: a name field (in fig. 8, "id: create-chain"), an identity field (in fig. 8, "id: create"), a text field (in fig. 8, "text: 'create'"), a description field (in fig. 8, "desc: 'create Hyperchain'"), an object field (in fig. 8, "target: chain"), a time field (in fig. 8, "time: 300"), and a tag field (in fig. 8, "tag: 'virtual lbox, cooling, k8 s'").

Step S260 in fig. 2 is described in detail below in conjunction with fig. 9. Fig. 9 is a schematic view of a drive package code file directory according to an embodiment of the present application.

In one possible manner, the code files are compiled and packaged into specified folders, e.g., web directories, each of which represents a respective driver page in a driver package, and the web folders are finally packaged into tar.gz files, i.e., blockchain driver packages. Wherein the web directory is an online list of websites and the tar.gz file is a compressed file with a suffix of tar.gz.

It should be understood that the web directories herein are merely exemplary descriptions for the selection of a specified folder, and that other choices for the specified folder are possible, and embodiments of the present application are not limited thereto.

Fig. 10 shows a schematic block diagram of a scaffold code file directory provided in an embodiment of the present application.

As shown in fig. 10, in one possible implementation, the page code includes, but is not limited to: a public file (also called public folder), a start script file, a source file directory (simply referred to as src directory) storing source code. The src directory includes, but is not limited to, an original resource folder (also called an assets folder) for storing static resources, a component folder (also called a components folder) for storing general components, a callback folder (also called a hops folder) for improving code reusability, a driver page folder (also called a pages folder) for storing generated driver pages, and a configuration file (including a package. Json file and an info. Yml file).

It should be understood that the above description of the scaffold code file directory is given by way of example only, and the scaffold code file directory may also include other subfolders, such as an entry folder (also referred to as main. Js), to which embodiments of the present application are not limited.

It should be understood that, the sequence number of each step in the foregoing embodiment does not mean the execution sequence, and the execution sequence of each process should be determined by the function and the internal logic of each process, and should not limit the implementation process of the embodiment of the present application in any way.

Corresponding to a method for generating a blockchain driving packet described in the above embodiments, fig. 11 shows a block diagram of an apparatus for generating a blockchain driving packet according to an embodiment of the present application, and for convenience of explanation, only a portion related to the embodiment of the present application is shown.

Referring to fig. 11, the apparatus 100 for generating a blockchain driving packet includes: a determining module 110, a generating module 120.

In some possible implementations, the determining module 110 is configured to determine a keyword matrix according to at least one first keyword and a second keyword, where the first keyword is a system keyword, the second keyword is a keyword generated based on the at least one first keyword, and the second keyword inherits dependency information of the first keyword;

optionally, the generating module 120 is configured to generate, according to the keyword matrix, a code file of a first driving page, where the code file of the first driving page includes a page description rendering file and a page style rendering file;

optionally, the generating module 120 is configured to generate a first driving configuration file according to the dependency information of the keyword matrix and the code file of the first driving page, where the first driving configuration file is used to install the driving dependency file of the first driving page.

In some possible implementations, the generating module 120 is configured to generate a second driving configuration file according to the code file of the first driving page, where the second driving configuration file is used to package the code file of the first driving page;

optionally, the generating module 120 is configured to determine a keyword matrix according to at least one first keyword and the second keyword, including:

Optionally, the generating module 120 is configured to generate a code file for driving a page according to the keyword matrix, including:

generating a second abstract syntax tree according to the keyword matrix;

Optionally, the generating module 120 is configured to generate a code file for driving a page, including: and generating a code file of the first driving page by using a natural language.

In some possible implementations, the generating module 120 is further configured to generate, according to the dependency information, a first driving configuration file, where the first driving configuration file is used to install a driving dependency file of the first driving page;

optionally, the generating module 120 is configured to generate a first driving configuration file according to the dependency information of the keyword matrix and the code file of the first driving page, including:

and generating the first driving configuration file according to one or more of the application dependency package field, the development environment dependency package field, the name field, the version field and the description field.

Optionally, the generating module 120 is configured to generate a second driving configuration file according to the code file of the first driving page, including:

Optionally, the second driving configuration file may be further used to interactively communicate with the back-end interface.

In some possible implementations, the generating module 120 is further configured to generate a blockchain driving package according to the first driving configuration file and the second driving configuration file.

Optionally, the generating module 120 is configured to generate a blockchain driving package according to the first driving configuration file and the second driving configuration file, including:

It should be understood that an apparatus for generating a blockchain driving packet according to an embodiment of the present application may correspond to the foregoing method embodiment, and the foregoing and other management operations and/or functions of each module in the apparatus for generating a blockchain driving packet are respectively for implementing the corresponding steps of the method in the foregoing method embodiment, so that beneficial effects in the foregoing method embodiment may also be implemented, which is not repeated herein for brevity.

Fig. 12 is a schematic structural diagram of an apparatus for generating a blockchain driving packet according to an embodiment of the present application. As shown in fig. 12, the apparatus 1200 includes: at least one processor 1210 (only one processor is shown in fig. 12), a memory 1220, and a computer program 12211 stored in the memory 1220 and executable on the at least one processor 1210, the processor 1210, when executing the computer program 1221, for implementing the steps in any of the various method embodiments described above for generating blockchain driving packages (such as the methods of fig. 2 through 7).

The apparatus 1200 may be a computing device such as a desktop computer, a notebook computer, a palm top computer, and a cloud server. The means for generating the blockchain driving package may include, but is not limited to, processor 1210, memory 1220. It will be appreciated by those skilled in the art that fig. 12 is merely an example of an apparatus 1200 that generates a blockchain drive package, and is not meant to be limiting of the apparatus 1200, and may include more or fewer components than shown, or may combine certain components, or different components, such as may also include input-output devices, network access devices, etc.

The processor 1210 may be a central processing unit (Central Processing Unit, CPU), the processor 1210 may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 1220 may be an internal storage unit of the apparatus 1200 in some embodiments, such as a hard disk or memory of the apparatus 1200 that generates the blockchain driving package. The memory 1220 may also be an external storage device of the apparatus 1200 in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the apparatus 1200. Further, the memory 1220 may also include both internal storage units and external storage devices of the apparatus 1200. The memory 1220 is used for storing an operating system, application programs, boot Loader (Boot Loader), data, other programs, etc., such as program codes of the computer program. The memory 1220 may also be used to temporarily store data that has been output or is to be output.

It should be noted that, because the content of information interaction and execution process between the above devices/units is based on the same concept as the method embodiment of the present application, specific functions and technical effects thereof may be referred to in the method embodiment section, and will not be described herein again.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps that may implement the various method embodiments described above.

Embodiments of the present application provide a computer program product which, when run on a mobile terminal, causes the mobile terminal to perform steps that may be performed in the various method embodiments described above.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application implements all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, where the computer program, when executed by a processor, may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a photographing device/terminal apparatus, recording medium, computer Memory, read-Only Memory (ROM), random access Memory (RAM, random Access Memory), electrical carrier signals, telecommunications signals, and software distribution media. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other manners. For example, the apparatus/network device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims

1. A method of generating a blockchain driving package, comprising:

2. The method of claim 1, wherein the method further comprises:

3. The method according to claim 1 or 2, wherein generating a code file of a first driving page from the keyword matrix comprises:

generating a second abstract syntax tree according to the keyword matrix;

4. The method of claim 1 or 2, wherein generating the code file of the first driver page comprises:

and generating a code file of the first driving page by using a natural language.

5. The method according to claim 1 or 2, wherein the generating a first driver configuration file from the dependency information of the key matrix and the code file of the first driver page comprises:

6. The method of claim 1 or 2, wherein generating a second driver profile from the code file of the first driver page comprises:

7. The method of claim 1 or 2, wherein generating a blockchain drive package from the first drive profile and the second drive profile comprises:

8. An apparatus for generating a blockchain driving package, comprising:

a determining module, configured to determine a keyword matrix according to at least one first keyword and a second keyword, where the first keyword is a system keyword, the second keyword is a keyword generated based on the at least one first keyword, and the second keyword inherits dependency information of the first keyword;

the generation module is used for generating a code file of a first driving page according to the keyword matrix, wherein the code file of the first driving page comprises a page description rendering file and a page style rendering file;

the generating module is further configured to generate a first driving configuration file according to the dependency information of the keyword matrix and the code file of the first driving page, where the first driving configuration file is used to install the driving dependency file of the first driving page;

The generating module is further configured to generate a second driving configuration file according to the code file of the first driving page, where the second driving configuration file is used to package the code file of the first driving page;

the generating module is further configured to generate a blockchain driving package according to the first driving configuration file and the second driving configuration file.

9. An apparatus for generating a blockchain drive package comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of any of claims 1 to 7 when executing the computer program.

10. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the method according to any one of claims 1 to 7.