A method and system for generating smart contract code

Abstract

The application discloses a kind of generation method and system of smart contract code. Method includes: in response to the input of initial smart contract source code, the initial smart contract source code is carried out lexical analysis and syntax analysis, and abstract syntax tree is generated, wherein the initial smart contract source code is obtained by being written through first programming language;Abstract syntax tree is traversed, and the node type of each node in abstract syntax tree is obtained;For any node, based on the node type of node, corresponding abstract syntax tree node processor is called to carry out syntax conversion to node, and node processing result suitable for target smart contract syntax rule is generated;Target smart contract code is generated based on the node processing result of each node.The scheme realizes the efficient, accurate and flexible automatic code conversion from initial smart contract source code to target smart contract code by introducing the dynamic scheduling mechanism of syntax element processor.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method and system for generating smart contract code. Background Technology

[0002] With the rapid development of blockchain technology, its decentralized, transparent, and immutable characteristics have been widely applied in many industries. Smart contracts, as a key technology of blockchain, can automatically execute protocols by running pre-defined logic code on the blockchain, thus becoming an important component driving the application of blockchain technology. The application of smart contracts has undoubtedly injected great vitality into the development of blockchain, but its development and deployment also face many challenges.

[0003] Currently, most smart contracts are developed using specialized programming languages ​​(such as Solidity and Vyper). While these languages ​​are powerful, their complex syntax and high learning curve often pose challenges for developers, especially traditional developers transitioning to the blockchain field who need to invest significant time and effort in learning and adapting. Furthermore, many existing smart contract programming languages ​​have high requirements for code rigor. While this enhances security, it also increases the pressure on ordinary developers when writing smart contracts. Considering the nascent and rapidly developing nature of the blockchain industry, lowering the development threshold and improving the efficiency of developers using smart contract languages ​​is crucial for the future development of the entire industry. Current industry trends indicate that simplifying the smart contract development process and enhancing language usability have become pressing issues that need to be addressed in blockchain-related development tools. Summary of the Invention

[0004] This invention provides a method and system for generating smart contract code to solve the problems of high difficulty and low efficiency in the development of existing smart contracts.

[0005] According to one aspect of the present invention, a method for generating smart contract code is provided, comprising: In response to the input of the initial smart contract source code, lexical analysis and syntax analysis are performed on the initial smart contract source code to generate an abstract syntax tree. The initial smart contract source code is written in a first programming language. Traverse the abstract syntax tree to obtain the node type of each node in the abstract syntax tree; For any node, based on the node type, the corresponding abstract syntax tree node processor is invoked to perform syntax transformation on the node, generating a node processing result that adapts to the target smart contract syntax rules; The target smart contract code is generated based on the node processing results of each node.

[0006] Optionally, lexical and syntactic analysis is performed on the initial smart contract source code to generate an abstract syntax tree. This includes: performing lexical analysis on the initial smart contract source code to break it down into a sequence of syntactic units, where the sequence of syntactic units includes keywords, identifiers, literals, operators, and delimiters; literals include address literals and numeric literals specific to the smart contract; performing syntactic analysis on the sequence of syntactic units based on the source language syntactic rules of the initial smart contract source code to obtain syntactic analysis results; and constructing an abstract syntax tree based on the hierarchical and structural relationships of the syntactic units in the syntactic analysis results. The abstract syntax tree includes node types, syntactic elements, and parent-child node association information. Node types include at least one of identifier type, literal type, expression type, statement type, and contract structure type. Syntactic elements include at least one of class declaration, function definition, variable declaration, type modifier, and event declaration. The type modifier includes prefer, which is used to define the types of variables, function return values, and parameters.

[0007] Optionally, traverse the abstract syntax tree to obtain the node type of each node in the abstract syntax tree, including: performing a full traversal of the abstract syntax tree from the root node to the leaf node in a depth-first traversal order, and extracting the node type of each node based on the built-in type identifier field of each node.

[0008] Optionally, based on the node type, the corresponding abstract syntax tree node processor is invoked to perform syntax transformation on the node, generating a node processing result that adapts to the target smart contract syntax rules. This includes: obtaining a preset mapping relationship between node types and abstract syntax tree node processor instances through a preset smart contract compiler; matching the node type with the mapping relationship to obtain an abstract syntax tree node processor instance that matches the node type; and invoking the abstract syntax tree node processor instance to perform syntax transformation on the node, obtaining a node processing result that adapts to the target smart contract syntax rules. The preset smart contract compiler includes abstract syntax tree node processor instances corresponding to each node type.

[0009] Optionally, the mapping relationship also includes the call priority of each abstract syntax tree node processor, which is used to determine the abstract syntax tree node processor instance that performs syntax transformation processing on the node based on the call priority when there are multiple node processors adapting to the same node type.

[0010] Optionally, the abstract syntax tree node processor includes at least a class declaration processor, a function declaration processor, a variable declaration processor, and an event processor. The class declaration processor is used to handle the conversion from class definition in the first programming language to contract definition in the target language; the function declaration processor is used to handle the conversion of function signature, parameters, and return type; the variable declaration processor is used to handle the conversion of variable type, visibility, and storage location; and the event processor is used to handle the conversion of event declaration and triggering conditions.

[0011] Optionally, generating target smart contract code based on the node processing results of each node includes: writing the node processing results of each node into a pre-built shared contract context object; determining the hierarchical relationship and structural association of the processing results of each node based on the parent-child node association information bound in the shared contract context object; and performing syntax splicing and serialization processing according to the syntax rules of the target smart contract to generate the target smart contract code. The shared contract context object includes a syntax rule storage module, a node result caching module, and a code splicing module. The syntax rule storage module pre-stores the syntax rules of the target smart contract and is used to verify the legality of the node processing results.

[0012] According to another aspect of the present invention, a smart contract code generation system is provided, comprising: The abstract syntax tree generation module is used to respond to the input of the initial smart contract source code, perform lexical analysis and syntax analysis on the initial smart contract source code, and generate an abstract syntax tree. The initial smart contract source code is written in a first programming language. The node type determination module is used to traverse the abstract syntax tree and obtain the node type of each node in the abstract syntax tree; The node processing result determination module is used to, for any node, call the corresponding abstract syntax tree node processor to perform syntax transformation on the node based on the node type, and generate the node processing result corresponding to the node that adapts to the target smart contract syntax rules. The target smart contract code determination module is used to generate target smart contract code based on the node processing results of each node.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory that is communicatively connected to at least one processor; wherein, The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to execute the method for generating smart contract code according to any embodiment of the present invention.

[0014] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute a method for generating smart contract code that implements any embodiment of the present invention.

[0015] The technical solution of this invention receives initial smart contract source code written in a first programming language as input. First, it performs lexical and syntactic analysis on the initial smart contract source code to generate a structured abstract syntax tree, transforming the text code into a structured abstract syntax tree. Then, it traverses the entire abstract syntax tree, extracting the node type of each node. Subsequently, for each node, it automatically calls the corresponding abstract syntax tree node processor based on its node type, completing the syntax conversion according to the syntax rules of the target smart contract, generating node processing results adapted to the target language. Finally, it integrates all node processing results in an orderly manner according to the syntax structure, ultimately generating complete and usable target smart contract code. This solution, through a fully automated, modular, and structured processing method, and by introducing a dynamic scheduling mechanism for syntax element processors, achieves accurate and efficient conversion of smart contracts from the source language to the target language. It avoids syntax errors and logical deviations without manual intervention, featuring a clear process, strong scalability, and high stability. This significantly improves the efficiency and reliability of smart contract cross-language conversion, compilation, and migration, providing efficient and secure technical support for contract compatibility and upgrades between blockchain platforms.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of a method for generating smart contract code according to Embodiment 1 of the present invention; Figure 2 This is a syntax element class mapping diagram applicable to the embodiments of the present invention; Figure 3 This is a schematic diagram of a function-to-function mapping applicable to an embodiment of the present invention.

[0019] Figure 4 This is a flowchart illustrating a smart contract compilation and code generation method applicable to an embodiment of the present invention; Figure 5 This is a schematic diagram of the control flow of traversing and processing the abstract syntax tree within a smart contract compiler applicable to embodiments of the present invention; Figure 6 This is a flowchart of a method for initializing a smart contract compilation environment and dynamically constructing a processor, applicable to an embodiment of the present invention. Figure 7 This is a schematic diagram of a smart contract compiler system architecture applicable to an embodiment of the present invention; Figure 8 This is a flowchart of a method for generating smart contract code according to Embodiment 2 of the present invention; Figure 9 This is a schematic diagram of the structure of a smart contract code generation system provided in Embodiment 3 of the present invention; Figure 10 This is a schematic diagram of the structure of an electronic device that implements the smart contract code generation method of this invention. Detailed Implementation

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

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

[0022] It's important to note that while the development of blockchain technology has made smart contracts a crucial application, the complex syntax and high learning curve of its mainstream development languages ​​(such as Solidity) hinder developers from adopting them. To lower this barrier, this solution proposes using a more user-friendly primary programming language (such as Phoenix, a language integrating object-oriented and functional programming) to write the logic, and then compiling it into smart contract code in the target programming language (such as Solidity). However, traditional compilers often employ hard-coded conversion logic when handling such cross-language, multi-structure mappings, leading to system rigidity, difficulty in expansion, and maintenance. When new syntax needs to be supported or new platforms need to be adapted, significant modifications to the core code are required, resulting in inefficiency and a high risk of errors. Therefore, a flexible and scalable compilation method is urgently needed to efficiently manage the conversion of various syntactic elements. This solution introduces a dynamic scheduling mechanism for syntax element processors to achieve efficient, accurate, and flexible automatic code conversion from easy-to-use source languages ​​(Phoenix) to complex target languages ​​(such as Solidity). That is, it enables efficient, accurate, and flexible automatic code conversion from initial smart contract source code to target smart contract code, significantly reducing the development threshold and improving the maintainability of the compiler.

[0023] Example 1 Figure 1 This is a flowchart of a smart contract code generation method provided in Embodiment 1 of the present invention. This embodiment is applicable to the generation of target smart contract code. This method can be executed by a smart contract code generation system, which can be implemented in hardware and / or software and can be configured in electronic devices such as computers and servers. Figure 1 As shown, the method includes: S110. In response to the input of the initial smart contract source code, perform lexical analysis and syntax analysis on the initial smart contract source code to generate an abstract syntax tree, wherein the initial smart contract source code is written in a first programming language.

[0024] Specifically, the initial smart contract source code can be understood as the original text code written by the developer using a first programming language according to its syntax specifications, used to define the logical functions of the smart contract. It is also the input object for the entire compilation and parsing process. The first programming language can be understood as the syntax system and coding standards followed in writing the initial smart contract, determining the code's writing format and semantic rules. It should be noted that, in this embodiment, compared to the target smart contract's programming language, the first programming language is lightweight, efficient, easy to learn and use, highly versatile, and highly maintainable. For example, the first programming language could be Phoenix. Phoenix incorporates the Harmony framework into its language design, supporting custom smart contract compilers to compile Phoenix code into smart contract code. Phoenix is ​​designed specifically for developers who wish to engage in post-AI era development. Its code files end with "ose" and are based on a concise syntax structure and innovative design philosophy, thus greatly reducing the development threshold for smart contracts, possessing a late-mover advantage, and more efficiently supporting the construction and expansion of blockchain applications. Abstract Syntax Tree (ABS) can be understood as a tree-like structure formed after irrelevant syntactic symbols such as spaces, semicolons, and parentheses are removed from the source code during compilation or parsing. It uses nodes to represent syntactic units such as variables, expressions, and statements, and uses hierarchical relationships to represent the logical nesting and execution order of the code. It does not care how the code is written, but only focuses on the semantic structure of the code. It is a key intermediate data structure for subsequent compilation, analysis, or optimization of smart contracts, facilitating syntax checking, code transformation, optimization, and other processing by compilers, interpreters, or code analysis tools. It can be obtained by calling pre-built lexical and syntactic analysis methods to perform lexical and syntactic analysis on the initial smart contract source code.

[0025] Specifically, taking the initial smart contract source code written in the first programming language as input, the core process uses lexical analysis to break down the source code into indivisible basic lexical units such as identifiers, keywords, and operators. Then, syntax analysis verifies whether the combination rules of the lexical units conform to the syntax rules of the first programming language. After eliminating syntax errors, the linear source code is transformed into a hierarchical and structured abstract syntax tree. This process first completes the character parsing and syntax verification of the source code, and then constructs a tree-shaped data structure that accurately reflects the logical structure of the code.

[0026] In this embodiment, by constructing an abstract syntax tree corresponding to the initial smart contract source code, the redundant format information of the source code can be completely removed, providing standardized and structured core data for subsequent smart contract compilation, vulnerability detection, and logic optimization, greatly reducing the complexity of contract code parsing and processing, and improving the efficiency of smart contract development.

[0027] Optionally, lexical and syntactic analysis is performed on the initial smart contract source code to generate an abstract syntax tree. This includes: performing lexical analysis on the initial smart contract source code to break it down into a sequence of syntactic units, where the sequence of syntactic units includes keywords, identifiers, literals, operators, and delimiters; literals include address literals and numeric literals specific to the smart contract; performing syntactic analysis on the sequence of syntactic units based on the source language syntactic rules of the initial smart contract source code to obtain syntactic analysis results; and constructing an abstract syntax tree based on the hierarchical and structural relationships of the syntactic units in the syntactic analysis results. The abstract syntax tree includes node types, syntactic elements, and parent-child node association information. Node types include at least one of identifier type, literal type, expression type, statement type, and contract structure type. Syntactic elements include at least one of class declaration, function definition, variable declaration, type modifier, and event declaration. The type modifier includes prefer, which is used to define the types of variables, function return values, and parameters.

[0028] Specifically, the syntactic unit sequence can be understood as an ordered set of basic units obtained by splitting the initial smart contract source code after lexical analysis. This includes, but is not limited to, keywords, identifiers, operators, delimiters, and smart contract-specific address literals and numeric literals; it is the most basic structured unit of the code. The node type can be understood as the classification identifier of each node in the abstract syntax tree, including but not limited to identifier type, literal type, expression type, statement type, and contract structure type. This clarifies the syntactic component attributes represented by each node and can be used to subsequently determine the corresponding abstract syntax tree node processor for syntactic transformation processing. The syntactic element can be understood as the core code structure carried by the abstract syntax tree, including but not limited to class declarations, function definitions, variable declarations, type modifiers, and event declarations; it is a key component constituting the complete logic and architecture of the smart contract.

[0029] Specifically, taking the initial smart contract source code as the processing object, the continuous text code is first precisely split through lexical analysis to complete the basic unit decomposition of the code. This can be split into a sequence of syntactic units, including keywords, identifiers, regular literals, and smart contract-specific address literals, numeric literals, operators, and delimiters. Then, the syntactic unit sequence is strictly analyzed according to the source language syntactic rules of the source code to verify the legality of the unit combination and sort out the corresponding syntactic analysis results. Finally, based on the syntactic unit hierarchy and structural relationship in the results, an abstract syntax tree is constructed, covering various node types such as identifiers, literals, expressions, statements, and contract structures, and containing syntactic elements such as class declarations, function definitions, variable declarations, type modifiers, and event declarations, as well as parent-child node relationship information.

[0030] In this embodiment, the refined parsing process of generating an abstract syntax tree not only fully adapts to the unique syntactic characteristics of smart contracts and accurately extracts and presents all the core logic and architectural information of the contract in a structured manner, but also efficiently identifies lexical and syntactic errors in the code at an early stage. This provides standardized and highly available structured intermediate data for the compilation, security auditing, logic verification, and code optimization of smart contracts, greatly improving the accuracy, efficiency, and reliability of smart contract development and testing.

[0031] S120. Traverse the abstract syntax tree and obtain the node type of each node in the abstract syntax tree.

[0032] Specifically, after generating the abstract syntax tree corresponding to the initial smart contract source code, the completed abstract syntax tree is used as the processing object. All nodes in the abstract syntax tree can be traversed in the preset node access order through recursion or iteration. During the traversal, the node type information corresponding to each node is read and extracted one by one, and finally the node type data of all nodes in the entire abstract syntax tree are obtained completely.

[0033] In this embodiment, by using an abstract syntax tree to obtain the type of each node, the features of the abstract syntax tree nodes can be extracted systematically and without omission. This allows for the rapid acquisition of the overall syntactic structure distribution of the smart contract code, providing accurate node classification criteria for subsequent targeted node analysis, code conversion, and other processing operations, thereby improving the flexibility and execution efficiency of smart contract code conversion.

[0034] Optionally, traverse the abstract syntax tree to obtain the node type of each node in the abstract syntax tree, including: performing a full traversal of the abstract syntax tree from the root node to the leaf node in a depth-first traversal order, and extracting the node type of each node based on the built-in type identifier field of each node.

[0035] The depth-first traversal order can be understood as the core order rule used when traversing the abstract syntax tree. It means starting from the root node, traversing downwards along a single branch until the lowest leaf node, and then backtracking to the previous node to continue traversing other branches. This achieves a complete, ordered, and comprehensive access to the entire tree from the root node to the leaf node. It should be noted that the depth-first traversal order can be set according to actual needs and is not limited here. The type identifier field can be understood as a unique attribute field inherent to each node in the abstract syntax tree. During the construction of the abstract syntax tree, the classification identifier of the corresponding node can be predefined and stored. This directly identifies which node type the node belongs to, such as identifier, literal, expression, statement, or contract structure, providing a direct basis for quickly and accurately extracting the node type.

[0036] Specifically, using the constructed abstract syntax tree as the processing object, a full and complete traversal of the entire abstract syntax tree is performed, strictly following a depth-first traversal order, starting from the root node and proceeding downwards to all leaf nodes. During the traversal, the built-in type identifier field of each node is directly read to accurately extract the node type corresponding to all nodes, thus obtaining the complete node classification information of the entire syntax tree. This standardized and structured traversal and extraction process ensures the orderliness and completeness of node access, and achieves efficient, stable, and unambiguous type acquisition by relying on the built-in fields of nodes.

[0037] In this embodiment, a depth-first traversal is adopted to fully traverse the abstract syntax tree from root to leaf. The node type is extracted through the built-in type field of the node, which ensures that the traversal is orderly and complete, the extraction is efficient and accurate, and the logic is stable and reliable. This provides a unified and reliable node type data foundation for subsequent operations, and greatly improves the accuracy and stability of subsequent code analysis and processing.

[0038] S130. For any node, based on the node type, call the corresponding abstract syntax tree node processor to perform syntax transformation on the node and generate the node processing result that adapts to the target smart contract syntax rules.

[0039] Specifically, the node processing result can be understood as the standardized processed data output by each node in the abstract syntax tree after undergoing syntactic transformation according to the target smart contract's syntax rules by its corresponding dedicated processor. It retains the core business logic and semantic information of the original node while completing syntactic adaptation, format correction, and attribute reconstruction from the source language to the target language, fully conforming to the target contract's syntax specifications. It is a crucial intermediate product between structured nodes and the final code, and also the direct foundational unit for subsequently splicing together the complete target smart contract code according to hierarchical relationships. The abstract syntax tree node processor is a syntax transformation execution unit specifically designed for different types of nodes in the abstract syntax tree. It is precisely invoked according to the node type, responsible for parsing, transforming, and reconstructing the source programming language syntax structure and elements corresponding to the node, ultimately outputting a processing result adapted to the target smart contract's syntax rules. It is the core execution component for realizing cross-language conversion of smart contract code. The processor has characteristics such as single responsibility, high code cohesion, and low coupling, facilitating independent development, testing, debugging, and reuse.

[0040] Specifically, for any single node in the abstract syntax tree, the node type is first read and identified. Then, based on different node types, the corresponding dedicated abstract syntax tree node processor is accurately matched and called. The abstract syntax tree node processor performs professional and targeted syntax transformation processing on the current node according to the syntax rules adapted to the target smart contract, and finally generates a node processing result that conforms to the syntax specifications of the target contract.

[0041] For example, in the process of converting smart contract code in a first programming language (Phoenix) to smart contract code in a target programming language (Solidity), it is necessary to analyze the syntactic elements of the source language code and map them to the corresponding syntactic structure of the target programming language. Specific steps include: 1. Parsing the source language contract structure. The converter receives the code in the first language (e.g., Phoenix) and maps it to the target language's corresponding syntactic structure. Figure 2 The diagram shows a syntax element mapping. The left side of the diagram shows the source code of a smart contract written in Phoenix code. This code includes class definition (class BobyCredToken extends Contract), import declarations (import), constructor (funt:()), and member variable declarations (such as t:name). 2: Mapping to the target language syntax structure. The system identifies each syntax element in the source language and generates an equivalent structure in the target language (Solidity) according to predefined mapping rules: 1) Mapping import statements to import statements. 2) Mapping class...extends Contract to contract...is Contract. 3) Mapping class member variable declarations (such as t:name, and the type description in the prefer block: Accessible String) to state variable declarations in Solidity (such as String private name;), and determining their visibility (such as public) based on the modifier scope. 4) Mapping the mapping structure (such as Dict...) to the target language syntax structure.<Address,Number> 5) Map the constructor parameters and assignment logic to the corresponding types in Solidity. 3: Generate target language code. After mapping, generate syntactically correct Solidity smart contract code, including a complete structure such as contract definition, event declaration, state variables, and constructor. This process demonstrates the ability to accurately convert from high-level, abstract source language descriptions to executable contract code for a specific blockchain platform (such as Ethereum).

[0042] In a specific embodiment, the detailed mapping method for converting source language (Phoenix language) smart contract functions into target language (Solidity smart contract language) functions, as described below, specifically addresses function body logic, state control, memory / storage model, and event mechanisms. The detailed mapping method is as follows: 1: Parse the source language function definition and modifiers. The converter reads the source language (Phoenix) function definition, including the function name (TransferBySafe), parameters, and key compiler directives and annotations (pragma-like annotations): 1) Scope (t:): Identifies the function's access permissions. 2) prefer:Payable->(...): Specifies the function's payment attribute. 3) $memoryx,y / $storage=z: Explicitly declares the variable's storage location (memory or on-chain storage). 4) $onSuccess / $onFail: Defines the events to be triggered when the function executes successfully or fails, and parameter mapping rules (e.g., _err automatically captures throw information). 2: Map function logic and control flow. The logical statements within the function body are converted line by line: 1) Variable declarations (let x = 1) are mapped to target language declarations with storage locations (uint memory x = 1;). 2) Conditional statements (case...) and error throwing (throw) are mapped to Solidity's case statements and the return pattern after the emit event (TransferFail) is triggered. 3) State updates (t:balances[from] -=amount) are directly mapped. 3: Generate target language functions and events. For example... Figure 3 The diagram illustrates a function-to-function mapping. Based on the annotations in step 1 and the logical mapping in step 2, the complete structure of the target language (Solidity) is generated as follows: 1) Generate event declarations (event TransferOK, eventTransferFail) corresponding to $onSuccess / $onFail. 2) Generate function signatures, integrating payable and external attributes. 3) Generate function bodies, correctly embedding logic, conditional statements, state updates, and event triggering (emit) statements. 4) Ensure that the declarations of memory and storage variables comply with the requirements of the blockchain execution environment.

[0043] It should be noted that if the node type is not identified, the corresponding abstract syntax tree can be skipped and the inner node processing can be skipped, directly proceeding to the subsequent context output stage without matching the node.

[0044] In this embodiment, by using a type-based, specialized execution mode, the processing requirements of different syntax nodes can be accurately adapted, ensuring that the processing results are highly matched with the target syntax rules. This achieves modular processing logic, strong targeting, and accurate and reliable conversion. It can flexibly adapt to multiple types of target syntax rules, effectively avoid syntax errors caused by general processing, and significantly improve the accuracy, stability, and scalability of abstract syntax tree conversion. This provides efficient and reliable node-level processing support for smart contract cross-platform migration, syntax upgrades, and code compilation.

[0045] In this embodiment, the abstract syntax tree node processor includes at least a class declaration processor, a function declaration processor, a variable declaration processor, and an event processor. The class declaration processor is used to handle the conversion from class definition in the first programming language to contract definition in the target language; the function declaration processor is used to handle the conversion of function signature, parameters, and return type; the variable declaration processor is used to handle the conversion of variable type, visibility, and storage location; and the event processor is used to handle the conversion of event declaration and triggering conditions.

[0046] It should be noted that, in order to achieve dedicated processor matching based on node type, the specific composition and division of labor of the abstract syntax tree node processors can be clearly defined in advance. Specifically, for different types of abstract syntax tree nodes identified through traversal, the corresponding class declaration processor, function declaration processor, variable declaration processor, and event processor are scheduled to perform specialized transformations. Among them, the class declaration processor is responsible for converting the class definition of the source programming language into the contract definition of the target language; the function declaration processor is responsible for completing the adaptation and conversion of function signatures, parameters, and return types; the variable declaration processor is responsible for handling the syntax conversion of variable types, visibility, and storage locations; and the event processor is responsible for implementing the conversion of event declarations and triggering conditions. Finally, the output is a processing result that conforms to the syntax rules of the target language. Its advantages are that it adopts a modular and specialized processing architecture, with different processors performing their respective duties without interfering with each other. This makes the syntax conversion logic of smart contracts clear, easy to maintain and expand, and can accurately cover the conversion needs of the core syntax structure of the contract. It can significantly improve the accuracy, stability, and execution efficiency of cross-language contract conversion, while also facilitating the optimization and upgrading of a certain type of processor without affecting the overall conversion process.

[0047] S140. Generate the target smart contract code based on the node processing results of each node.

[0048] Specifically, the target smart contract code can be understood as the complete contract text code that conforms to the syntax specifications of the target programming language and the requirements of the contract execution environment. For example, the target programming language could be the Solidity smart contract language. The target smart contract code fully retains the core business logic, functional structure, and execution semantics of the initial smart contract source code. It is the final output that can be directly compiled, deployed, and run on the target blockchain platform. It can be generated after a series of automated processes such as lexical analysis, syntax analysis, abstract syntax tree construction, node traversal, and syntax transformation.

[0049] Specifically, based on the node processing results obtained by transforming all nodes in the abstract syntax tree through a dedicated processor and adapting them to the target language syntax rules, the node processing results are sequentially spliced, integrated, and formatted according to the node hierarchy and parent-child node association structure of the original abstract syntax tree. Finally, the target smart contract code that conforms to the target smart contract syntax specification and whose logic is consistent with the original contract is fully generated.

[0050] In this embodiment, the code is restored based on the structured node processing results and strict hierarchical relationships, ensuring the syntactic correctness and logical integrity of the converted code. This makes the smart contract code generation process standardized and highly automated, accurately restoring all the functional logic of the original contract. It avoids syntax errors and logical deviations caused by manual rewriting, greatly improving the efficiency and reliability of smart contract cross-language migration, compilation, and upgrade. At the same time, it adapts to the modular processing results of various node types, possessing good compatibility and scalability.

[0051] It should be noted that this embodiment uses a pre-built compiler to parse the Phoenix source code into an Abstract Syntax Tree (AST) with type information in the early stages. Later, instead of using fixed transformation rules, the AST is traversed, and for each syntax node, a pre-registered dedicated processor (GrammarElement) is dynamically located and invoked based on its type identifier (TypeID) using the processor organization and scheduling mechanism. Each processor independently maps specific types of Phoenix syntax elements (such as class declarations, function definitions, and variable modifiers) to their equivalent Solidity structure and writes the generated code snippets into a shared ContractContext object. Finally, the system integrates all snippets in the context and outputs the complete Solidity contract code. Regarding the processor organization and scheduling mechanism, it includes: a unified interface and registration: defining a standard GrammarElement interface, which all concrete processors (such as ClassDeclaration and FixHeader) implement to ensure consistent behavior. A ProcessorBuilder is established as a registry center, maintaining a mapping table from TypeID to processor instances. During compiler initialization, each processor registers with this builder. Dynamic Scheduling and Execution: During AST traversal, for each node, the scheduler queries the ProcessorBuilder, retrieves the corresponding processor based on the node's TypeID, and executes its processing logic. This achieves complete decoupling between the processing logic and the compiler's core control flow. Context Sharing and Collaboration: The ContractContext object acts as an "information hub" for the compilation process, storing global state (such as contract names, event lists, and generated functions). All processors receive and manipulate this context, ensuring that the generated code snippets can be correctly assembled into a syntactically and semantically consistent whole.

[0052] Optionally, generating target smart contract code based on the node processing results of each node includes: writing the node processing results of each node into a pre-built shared contract context object; determining the hierarchical relationship and structural association of the processing results of each node based on the parent-child node association information bound in the shared contract context object; and performing syntax splicing and serialization processing according to the syntax rules of the target smart contract to generate the target smart contract code. The shared contract context object includes a syntax rule storage module, a node result caching module, and a code splicing module. The syntax rule storage module pre-stores the syntax rules of the target smart contract and is used to verify the legality of the node processing results.

[0053] Specifically, the shared contract context object can be understood as a pre-built unified management container that integrates a syntax rule storage module, a node result caching module, and a code concatenation module. It is used to uniformly store the target smart contract's syntax rules, cache node processing results, and support ordered code concatenation and legality verification. Parent-child node association information can be understood as the node hierarchy relationships inherent in the abstract syntax tree, used to mark the hierarchical relationships between nodes. The hierarchical relationship of each node's processing results can be understood as the hierarchical structure between node processing results reconstructed based on the parent-child node association information. Structural association can be understood as the logical combination and syntactic collocation relationships between node processing results. The hierarchical relationship and structural association of each node's processing results together ensure that the code is generated and concatenated according to the correct logical structure and syntactic specifications.

[0054] Specifically, based on the processing results of each node, the processing results of all nodes that are adapted to the target language syntax are first written into a pre-built shared contract context object. The hierarchical relationship and structural association of the processing results of each node are accurately determined according to the parent-child node association information bound in the shared contract context object. Then, the node results are validated for legality by the target smart contract syntax rules stored in the syntax rule storage module within the context object. Subsequently, the node result caching module temporarily stores the validated node data. Finally, the code splicing module completes the syntax splicing and serialization processing according to the target syntax rules, and finally automatically generates complete, standardized, and directly runnable target smart contract code.

[0055] In this embodiment, a structured generation process based on shared contract context objects achieves integrated processing of unified node data management, accurate restoration of structural relationships, and pre-validation of syntax rules. This makes the code generation process more standardized, data flow more unified, and the verification mechanism more complete. It can effectively avoid splicing errors, structural chaos, and syntax violations, and significantly improve the correctness, readability, and stability of the target contract code. At the same time, the modular context design makes the process easier to maintain, expand, and debug, providing efficient and reliable standardized support for cross-language conversion and compilation of smart contracts.

[0056] In a specific embodiment, such as Figure 4The diagram illustrates a flowchart of a smart contract compilation and code generation method. The steps are as follows: 1. User writes initial smart contract code: The user writes the business logic code for the smart contract using a first programming language (Phoenix). 2. Execute compilation: The user initiates a compilation command through a command-line tool (such as Rose). This tool calls the smart contract compiler to perform lexical and syntactic analysis on the input Phoenix source code, constructing an Abstract Syntax Tree (AST). This AST not only contains the structural information of the code but also includes rich semantic annotations such as type information. 3. Perform syntax element transformation: The compiler backend receives the Phoenix AST with type information. Its core converter traverses the AST nodes, mapping each Phoenix language syntax element (such as class definition, function declaration, variable type, modifier, etc.) to the corresponding syntax elements of the target smart contract language (such as Solidity) according to predefined transformation rules. This step generates a new, target-language-oriented intermediate representation or AST containing target language syntax elements. 4. Generate target contract code: The code generator traverses and formats the output based on the abstract syntax tree obtained after conversion, which contains the syntax elements of the target language, and finally generates complete smart contract source code (such as .sol file) and files for deployment (.bin file).

[0057] In a specific embodiment, such as Figure 5 The diagram illustrates the control flow of a smart contract compiler traversing and processing the abstract syntax tree. The specific flow is as follows: S501: Initialize the compilation environment: The compiler receives the input Phoenix Contract Abstract Syntax Tree (PhoenixContract Ast) and starts the code generation process. First, it initializes the contract compilation environment (Init Contract Environment) by creating and configuring context objects such as ContractContext.

[0058] S502: Traversing the Abstract Syntax Tree (AST) Nodes. The system begins traversing the input AST. For each currently traversed node: 1) First, determine if the node is a typeless node (GenNoTypeNode). 2) If it is a typeless node, proceed directly to the subsequent judgment or processing flow (No path). 3) If it is a typed node (Yes path), then through the GetProcessor operation, dispatch the corresponding syntax element processor (GrammarElement implementation) from the processor creator ProcessorBuilder's procMap based on the node's type (TypeID).

[0059] S503: Processor Execution and Recursive Processing: The assigned processor performs specific processing on the current node (Process Current Node), such as generating code snippets and writing them to the ContractContext. After processing, the system determines whether the node contains internal child nodes that require further processing (Need Process Inner Node?). 1) If yes, the process returns to step S502 to recursively traverse and process its child nodes. 2) If no, the process continues traversing the syntax tree to the next sibling node.

[0060] S504: Output Compilation Results: After the entire abstract syntax tree has been traversed and processed, the compilation context integrates all the code fragments generated by the processors and performs the final output, generating the binary code, metadata, or other artifacts (Bin / Metadata) of the target smart contract. In the diagram, Call SoleWrapper indicates a possible call to a module that wraps or optimizes the final code.

[0061] In a specific embodiment, such as Figure 6 The flowchart shown illustrates a method for initializing a smart contract compilation environment and dynamically constructing a processor. This method provides the necessary context and tools for subsequent syntax tree traversal and code generation. The steps are as follows: S601: Initial Compiler Environment. In response to a compilation request, the system initiates the Initial Compiler Environment process. This step aims to establish the basic runtime framework for the upcoming contract compilation task.

[0062] S602: Create ContractContext: First, a ContractContext object is created. This context object serves as a core data structure, used to carry and pass state information throughout the entire compilation lifecycle, including but not limited to the contract name, symbol table, list of generated events and functions, and temporary variable storage, providing a unified access and operation interface for the code generation of various syntax elements.

[0063] S603: Inject Traverse Callback Proc. The system registers a predefined handler function as a callback function for the syntax tree traversal process. This handler function specifies the standard operational logic to be executed when traversing each node of the abstract syntax tree, such as node type determination and processor dispatch, thereby decoupling the compiler's core control logic from specific syntax processing.

[0064] S604: Initialize the ProcessorBuilder. The system initializes a ProcessorBuilder component (InitProcessorBuilder). This builder manages and maintains a mapping that associates different types of syntax element nodes with their corresponding dedicated handlers. Its initialization process may include loading the default processor registry or preparing the processor factory.

[0065] S605: Build and return the context and processor set. The processor builder constructs the complete set of processors needed to handle this compilation task, based on predefined rules or dynamic configuration. These processors may specifically include: 1) Rollup SDK Compiler Handler: used to handle special syntax or built-in functions related to the software development kit (SDK) of a specific Rollup solution. 2) Rollup Grammar Handler: used to handle syntax structures or contract properties specific to the Rollup environment. The initialization process ultimately returns the created ContractContext object and the completed set of Processors (Return Context & Processor) to the compiler's core driver module, signifying that the compilation environment is ready.

[0066] In a specific embodiment, such as Figure 7 The diagram illustrates a smart contract compiler system architecture. This architecture is modular and scalable, and specifically includes: S701: Defines the syntax element interface and registration mechanism. The system defines a unified GrammarElement interface, requiring all concrete syntax element processing components (such as ClassDeclaration, CodeGen) to implement methods such as Generate, Parse, GetType, and Register. Simultaneously, the system provides a ProcessorBuilder, which maintains a procMap for registering and finding the corresponding handler (proc) based on the syntax element's TypeID. This achieves decoupling between processing logic and syntax types.

[0067] S702: Implements the core compilation components. 1) SolidityCompiler: As the backend engine of the compiler, it coordinates the entire compilation process. 2) ContractContext: As the compilation context object, it collects and passes information during compilation, such as the contract name, event list, and function list, and provides methods such as PushEvent, PushFunction, and Output for each syntax element handler to call. 3) FixHeader, ClassDeclaration, etc.: As implementations of specific GrammarElements, they are responsible for handling specific types of syntax nodes (such as code generation, class declarations, etc.).

[0068] S703: Execute the layered processing flow. The compiler workflow follows a layered architecture: the Bobychain layer provides support for basic Solidity properties; the Contract SDK layer provides utility methods; ContractContext and SolidityCompiler constitute the core compilation layer; and the specific GrammarElement implementations constitute the element processing layer. SolidityCompiler calls ProcessorBuilder to assign nodes to corresponding processors based on their type. The processors use ContractContext to generate code snippets, which are ultimately integrated and output by the context.

[0069] The technical solution of this embodiment receives initial smart contract source code input written in a first programming language. First, it performs lexical and syntactic analysis on the initial smart contract source code to generate a structured abstract syntax tree (AST), transforming the text code into a structured AST. Then, it traverses the entire AST, extracting the node type of each node. Subsequently, for each node, it automatically calls the corresponding AST node processor based on its node type, completing the syntax conversion according to the target smart contract's syntax rules, generating node processing results adapted to the target language. Finally, it integrates all node processing results in an orderly manner according to the syntactic structure, ultimately generating complete and usable target smart contract code. This solution, through a fully automated, modular, and structured processing method, and the introduction of a dynamic scheduling mechanism for syntax element processors, achieves accurate and efficient conversion of smart contracts from the source language to the target language. It avoids syntax errors and logical deviations without manual intervention, featuring a clear process, strong scalability, and high stability. This significantly improves the efficiency and reliability of cross-language conversion and compilation migration of smart contracts, providing efficient and secure technical support for contract compatibility and upgrades between blockchain platforms.

[0070] Example 2 Figure 8 This is a flowchart of a method for generating smart contract code according to Embodiment 2 of the present invention. The method in this embodiment is a further optimization of the method in the above embodiments. Optionally, a preset mapping relationship between node types and abstract syntax tree (AST) node processor instances is obtained through a preset smart contract compiler. Matching is performed based on the node types and mapping relationships to obtain AST node processor instances that match the node types. The preset smart contract compiler includes AST node processor instances corresponding to each node type. The AST node processor instances are then called to perform syntax transformation processing on the nodes to obtain node processing results that adapt to the syntax rules of the target smart contract. Figure 8 As shown, the method includes: S810, In response to the input of the initial smart contract source code, perform lexical analysis and syntax analysis on the initial smart contract source code to generate an abstract syntax tree, wherein the initial smart contract source code is written in a first programming language.

[0071] S820. Traverse the abstract syntax tree and obtain the node type of each node in the abstract syntax tree.

[0072] S830. For any node, obtain the mapping relationship between the preset node type and the abstract syntax tree node processor instance through the preset smart contract compiler, and match the node type and the mapping relationship to obtain the abstract syntax tree node processor instance that matches the node type.

[0073] The preset smart contract compiler includes abstract syntax tree node processor instances corresponding to each node type.

[0074] Specifically, an abstract syntax tree (AST) node processor instance can be understood as a directly invoked processing object specifically created based on the node type. It includes concrete, runnable processing units such as class declaration processors and function declaration processors, used to perform syntax transformation operations on nodes of the corresponding type. The mapping relationship can be understood as a pre-defined correspondence rule between node types and AST node processor instances. This rule can be stored in a pre-built node type index table, allowing the system to quickly find and invoke the matching processor instance based on the node type, without repeated judgment or creation.

[0075] Specifically, for any node in the abstract syntax tree, a pre-configured mapping relationship between node types and abstract syntax tree node processor instances is obtained through a pre-set smart contract compiler. Then, the node type of the current node is searched and matched with this mapping relationship to quickly find and obtain an abstract syntax tree node processor instance that is fully compatible with the node type. This matching mechanism based on the pre-set mapping achieves the decoupling and fast scheduling of node types and processors.

[0076] In this embodiment, the node type and mapping relationship of the node are matched to obtain the abstract syntax tree node processor instance that matches the node type, so as to realize the automatic distribution of the abstract syntax tree node processor instance. This facilitates the addition, modification or deletion of node types and corresponding processors, greatly improving the modularity, maintainability and scalability of the system, and providing a stable and reliable scheduling foundation for the standardization and specialization of subsequent nodes.

[0077] Optionally, the mapping relationship also includes the call priority of each abstract syntax tree node processor, which is used to determine the abstract syntax tree node processor instance that performs syntax transformation processing on the node based on the call priority when there are multiple node processors adapting to the same node type.

[0078] In this context, the call priority can be understood as a pre-defined ranking rule for the abstract syntax tree node processors. This rule is used to determine the execution order when multiple processors can adapt to the same node type. The system will automatically select the processor with the highest priority value or the highest level as the unique execution unit to perform syntax transformation on the current node, thereby avoiding processing conflicts and ensuring that the execution logic is unique and controllable.

[0079] Specifically, in addition to the existing mapping relationship between node types and abstract syntax tree node processor instances, the system also incorporates the call priority configuration for each processor. When multiple processors are adapted to the same node type, the system will automatically sort and filter them according to the preset call priority to determine the only abstract syntax tree node processor instance with execution permission, and perform precise syntax transformation processing on the current node based on that instance. This mapping mechanism with priority scheduling makes processor adaptation more flexible and controllable.

[0080] In this embodiment, the abstract syntax tree node processor instance for syntax conversion processing is determined by combining the call priority. This can effectively solve the multi-processor conflict problem, ensure the uniqueness and stability of node processing, support dynamic expansion and compatibility with processor logic of different versions and scenarios, and achieve flexible switching of processing rules without modifying the core code. This greatly improves the compatibility, scalability and scenario adaptability of the smart contract syntax conversion system.

[0081] S840: Call the abstract syntax tree node processor instance to perform syntax transformation processing on the node, and obtain the node processing result that adapts to the syntax rules of the target smart contract.

[0082] Specifically, after successfully matching an abstract syntax tree node processor instance corresponding to the node type, the dedicated processor instance is directly called to perform targeted parsing, transformation, and reconstruction of the current node's syntax content, structural attributes, and other information. It strictly follows the syntax rules of the target smart contract to complete the adaptation and adjustment of core syntax elements such as variable types, function signatures, contract structure, and visibility, and finally outputs node processing results that fully conform to the target language syntax specifications and can be directly used for code concatenation.

[0083] In this embodiment, by calling a dedicated processor to perform a precise syntax conversion process, a refined and professional adaptation from the source language to the target language is achieved. This makes the conversion logic highly targeted and the syntax adaptation highly accurate. It can effectively avoid syntax errors and logical deviations caused by general conversion, ensure the compliance and correctness of the node processing results, and make the conversion process more efficient and stable, providing a solid guarantee for the final generation of high-quality target smart contract code.

[0084] S850 generates target smart contract code based on the node processing results of each node.

[0085] The technical solution of this embodiment receives initial smart contract source code input written in a first programming language, constructs a structured abstract syntax tree through lexical and syntactic analysis, obtains the node type of each node in the tree according to traversal rules, and precisely matches a corresponding dedicated processor for each node based on a preset mapping relationship between node type and processor instance. Then, the matched processor is invoked to perform syntax conversion processing on the node, generating a node processing result that conforms to the target smart contract syntax rules. Finally, all node processing results are integrated and a complete and usable target smart contract code is generated according to the target syntax specification. This solution achieves accurate and efficient conversion of smart contracts from the source language to the target language through a fully automated, modular, and structured processing method, and introduces a dynamic scheduling mechanism for syntax element processors. It has outstanding advantages such as accurate and efficient conversion, clear and decoupled logic, standardized processing flow, and strong scalability. It can completely avoid syntax errors and logical deviations caused by manual coding, and completes code verification and structured parsing in advance, significantly improving the efficiency, security, and reliability of smart contract cross-language migration, compilation, and upgrades. At the same time, the modular processor design and mapping mechanism facilitate flexible expansion of node types and conversion rules, and can efficiently adapt to diverse blockchain platforms and programming language environments.

[0086] Example 3 Figure 9 This is a schematic diagram of the structure of a smart contract code generation system provided in Embodiment 3 of the present invention. Figure 9 As shown, the system includes: Abstract syntax tree generation module 910 is used to respond to the input of the initial smart contract source code, perform lexical analysis and syntax analysis on the initial smart contract source code, and generate an abstract syntax tree, wherein the initial smart contract source code is written in a first programming language; The node type determination module 920 is used to traverse the abstract syntax tree and obtain the node type of each node in the abstract syntax tree; The node processing result determination module 930 is used to, for any node, call the corresponding abstract syntax tree node processor to perform syntax transformation on the node based on the node type, and generate a node processing result that adapts to the target smart contract syntax rules. The target smart contract code determination module 940 is used to generate target smart contract code based on the node processing results of each node.

[0087] The technical solution of this embodiment, in response to the input of the initial smart contract source code, performs lexical and syntactic analysis on the initial smart contract source code to generate an abstract syntax tree (AST). The initial smart contract source code is written in a first programming language. A node type determination module traverses the AST to obtain the node type of each node. For any given node, a node processing result determination module, based on the node type, calls the corresponding AST node processor to perform syntax transformation, generating a node processing result adapted to the target smart contract's syntax rules. Finally, a target smart contract code determination module generates the target smart contract code based on the node processing results of each node. This solution, through a fully automated, modular, and structured processing approach, and by introducing a dynamic scheduling mechanism for syntax element processors, achieves accurate and efficient conversion of smart contracts from the source language to the target language. It avoids syntax errors and logical deviations without manual intervention, featuring a clear process, strong scalability, and high stability. This significantly improves the efficiency and reliability of cross-language conversion and compilation migration of smart contracts, providing efficient and secure technical support for contract compatibility and upgrades between blockchain platforms.

[0088] Based on the above embodiments, optionally, the abstract syntax tree generation module 910 is specifically used to perform lexical analysis on the initial smart contract source code, splitting it into a sequence of syntax units, wherein the sequence of syntax units includes keywords, identifiers, literals, operators, and delimiters, and the literals include address literals and numeric literals specific to the smart contract; based on the source language syntax rules of the initial smart contract source code, the sequence of syntax units is subjected to syntax analysis to obtain syntax analysis results; based on the syntax unit hierarchical relationship and syntax structure relationship in the syntax analysis results, an abstract syntax tree is constructed, wherein the abstract syntax tree includes node types, syntax elements, and parent-child node association information, the node types include at least one of identifier type, literal type, expression type, statement type, and contract structure type, the syntax elements include at least one of class declaration, function definition, variable declaration, type modifier, and event declaration, and the type modifier includes prefer, which is used to define the type of variables, function return values, and parameters.

[0089] Optionally, the node type determination module 920 is specifically used to perform a full traversal of the abstract syntax tree from the root node to the leaf node in a depth-first traversal order, and extract the node type of each node based on the built-in type identifier field of each node.

[0090] Optionally, the node processing result determination module 930 is specifically used to obtain a preset mapping relationship between node types and abstract syntax tree node processor instances through a preset smart contract compiler; match the node types with the mapping relationship to obtain an abstract syntax tree node processor instance that matches the node type; wherein the preset smart contract compiler includes abstract syntax tree node processor instances corresponding to each node type; and call the abstract syntax tree node processor instance to perform syntax transformation processing on the node to obtain a node processing result that adapts to the syntax rules of the target smart contract. Optionally, the mapping relationship also includes the calling priority of each abstract syntax tree node processor, which is used to determine the abstract syntax tree node processor instance for syntax transformation processing of the node based on the calling priority when multiple node processors adapt to the same node type.

[0091] Optionally, the abstract syntax tree node processor includes at least a class declaration processor, a function declaration processor, a variable declaration processor, and an event processor. The class declaration processor is used to handle the conversion from class definition in the first programming language to contract definition in the target language; the function declaration processor is used to handle the conversion of function signature, parameters, and return type; the variable declaration processor is used to handle the conversion of variable type, visibility, and storage location; and the event processor is used to handle the conversion of event declaration and triggering conditions.

[0092] Optionally, the target smart contract code determination module 940 is specifically used to write the node processing results of each node into a pre-built shared contract context object, determine the hierarchical relationship and structural relationship of the processing results of each node based on the parent-child node association information bound in the shared contract context object, and perform syntax splicing and serialization processing according to the syntax rules of the target smart contract to generate the target smart contract code; wherein, the shared contract context object includes a syntax rule storage module, a node result caching module and a code splicing module, the syntax rule storage module pre-stores the syntax rules of the target smart contract and is used to perform legality verification of the node processing results.

[0093] The smart contract code generation system provided in this embodiment of the invention can execute the smart contract code generation method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0094] Example 4 Figure 10This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0095] like Figure 10 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0096] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0097] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as methods for generating smart contract code.

[0098] In some embodiments, the method for generating smart contract code may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method for generating smart contract code described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the method for generating smart contract code by any other suitable means (e.g., by means of firmware).

[0099] Various embodiments of the systems and techniques described above herein can be implemented in digital circuit systems, integrated circuits, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, at least one input device, and at least one output device.

[0100] Computer programs used to implement the smart contract code generation method of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0101] Example 5 Embodiment 5 of the present invention also provides a computer-readable storage medium storing computer instructions for causing a processor to execute a method for generating smart contract code, the method comprising: In response to the input of the initial smart contract source code, lexical analysis and syntax analysis are performed on the initial smart contract source code to generate an abstract syntax tree. The initial smart contract source code is written in a first programming language. Traverse the abstract syntax tree to obtain the node type of each node in the abstract syntax tree; For any node, based on the node type, the corresponding abstract syntax tree node processor is invoked to perform syntax transformation on the node, generating a node processing result that adapts to the target smart contract syntax rules; The target smart contract code is generated based on the node processing results of each node.

[0102] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0103] To provide interaction with an object, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the object; and a keyboard and pointing device (e.g., a mouse or trackball) through which the object provides input to the electronic device. Other types of devices can also be used to provide interaction with the object; for example, feedback provided to the object can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the object can be received in any form (including sound input, voice input, or tactile input).

[0104] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., a computer with a graphical user interface or web browser through which an item can interact with the implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0105] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0106] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0107] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for generating smart contract code, characterized in that, include: In response to the input of the initial smart contract source code, lexical analysis and syntax analysis are performed on the initial smart contract source code to generate an abstract syntax tree, wherein the initial smart contract source code is written in a first programming language; Traverse the abstract syntax tree to obtain the node type of each node in the abstract syntax tree; For any node, based on the node type, the corresponding abstract syntax tree node processor is invoked to perform syntax transformation on the node, generating a node processing result that adapts to the target smart contract syntax rules. The target smart contract code is generated based on the node processing results of each node.

2. The method according to claim 1, characterized in that, The step of performing lexical and syntactic analysis on the initial smart contract source code to generate an abstract syntax tree includes: Lexical analysis is performed on the initial smart contract source code to break it down into a sequence of syntactic units, wherein the sequence of syntactic units includes keywords, identifiers, literals, operators and delimiters, and the literals include address literals and numeric literals specific to the smart contract. Based on the source language syntax rules of the initial smart contract source code, the syntax unit sequence is subjected to syntax analysis to obtain the syntax analysis result. Based on the hierarchical relationship of grammatical units and the grammatical structure relationship in the grammatical analysis results, the abstract syntax tree is constructed. The abstract syntax tree includes node types, grammatical elements, and parent-child node association information. The node types include at least one of identifier type, literal type, expression type, statement type, and contract structure type. The grammatical elements include at least one of class declaration, function definition, variable declaration, type modifier, and event declaration. The type modifier includes prefer, which is used to define the type of variables, function return values, and parameters.

3. The method according to claim 1, characterized in that, The step of traversing the abstract syntax tree and obtaining the node type of each node in the abstract syntax tree includes: Following a depth-first traversal order, a full traversal is performed from the root node to the leaf node of the abstract syntax tree. Based on the type identifier field built into each node, the node type of each node is extracted.

4. The method according to claim 1, characterized in that, Based on the node type, the corresponding abstract syntax tree node processor is invoked to perform syntax transformation on the node, generating a node processing result that adapts the target smart contract syntax rules to the node, including: The preset smart contract compiler obtains a mapping relationship between preset node types and abstract syntax tree node processor instances, and matches the node types of the nodes with the mapping relationship to obtain abstract syntax tree node processor instances that match the node types. The preset smart contract compiler includes abstract syntax tree node processor instances corresponding to each node type. The abstract syntax tree node processor instance is invoked to perform syntax transformation processing on the node, thereby obtaining the node processing result that adapts to the syntax rules of the target smart contract.

5. The method according to claim 4, characterized in that, The mapping relationship also includes the calling priority of each abstract syntax tree node processor, which is used to determine the abstract syntax tree node processor instance that performs syntax transformation processing on the node based on the calling priority when there are multiple node processors adapting to the same node type.

6. The method according to claim 1, characterized in that, The abstract syntax tree node processor includes at least a class declaration processor, a function declaration processor, a variable declaration processor, and an event processor. The class declaration processor is used to handle the conversion from class definition in the first programming language to contract definition in the target language. The function declaration processor is used to handle the conversion of function signature, parameters, and return type. The variable declaration processor is used to handle the conversion of variable type, visibility, and storage location. The event processor is used to handle the conversion of event declaration and triggering conditions.

7. The method according to claim 1, characterized in that, The generation of target smart contract code based on the node processing results of each node includes: The node processing results of each node are written into a pre-built shared contract context object. Based on the parent-child node association information bound in the shared contract context object, the hierarchical relationship and structural association of the processing results of each node are determined. Syntax splicing and serialization are performed according to the syntax rules of the target smart contract to generate the target smart contract code. The shared contract context object includes a syntax rule storage module, a node result caching module, and a code concatenation module. The syntax rule storage module pre-stores the syntax rules of the target smart contract and is used to verify the legality of the node processing results.

8. A smart contract code generation system, characterized in that, include: An abstract syntax tree generation module is used to respond to the input of initial smart contract source code, perform lexical analysis and syntax analysis on the initial smart contract source code, and generate an abstract syntax tree, wherein the initial smart contract source code is written in a first programming language; The node type determination module is used to traverse the abstract syntax tree and obtain the node type of each node in the abstract syntax tree; The node processing result determination module is used to, for any node, based on the node type of the node, call the corresponding abstract syntax tree node processor to perform syntax transformation on the node, and generate the node processing result corresponding to the node that adapts to the target smart contract syntax rules; The target smart contract code determination module is used to generate target smart contract code based on the node processing results of each node.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method for generating smart contract code according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method for generating smart contract code according to any one of claims 1-7.

Images