Processing method and processing apparatus for smart contract on blockchain

Abstract

Provided in the present application are a processing method and processing apparatus for a smart contract on a blockchain. The processing method comprises: acquiring a first syntax tree corresponding to a source contract; identifying risk nodes from the first syntax tree, wherein the risk nodes relate to risk operations; and performing at least one of the following processings on the first syntax tree to obtain a second syntax tree: replacing a first risk node among the risk nodes with a first security node, wherein the first risk node relates to a first risk operation, the first security node relates to a first security operation, and the first security operation is used to replace the first risk operation; alternatively, adding a permission checking condition to a second risk node among the risk nodes, wherein the permission checking condition is used to determine the identity of a caller when a function indicated by the second risk node is called. The solution of the embodiments of the present application helps to improve the security of a smart contract.

Description

Blockchain smart contract processing method and processing device

[0001] This application claims priority to the Chinese patent application with application number 202311243785.0 filed with the State Intellectual Property Office of China on September 25, 2023, priority to the Chinese patent application with invention name “Method and device for processing domain-specific language”, priority to the Chinese patent application with application number 202311823929.X filed with the State Intellectual Property Office of China on December 27, 2023, and priority to the Chinese patent application with invention name “Method and device for processing smart contracts of blockchain”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of smart contract technology, and more specifically, to a method and device for processing smart contracts on a blockchain. Background Art

[0003] Blockchain provides a trusted channel for information and value exchange across untrusted networks, effectively addressing the data falsification inherent in traditional transactions. Smart contracts are executable code that can be deployed on the blockchain, automatically executing contracts on behalf of all parties involved without relying on a central authority. As smart contract technology continues to evolve, the number of supported scenarios has expanded, and business logic has become increasingly complex, leading to a series of limitations in smart contract languages.

[0004] In recent years, vulnerabilities related to smart contracts have emerged one after another, posing security risks to higher-level applications. Insecure smart contracts can undermine the stability of the blockchain and infringe on the security of user assets. Furthermore, compared to other programs, smart contracts deployed on the blockchain are difficult to modify. Once these vulnerabilities are exploited through targeted attacks, they can cause significant losses.

[0005] Therefore, how to improve the security of smart contracts has become an urgent problem to be solved.

[0006] Summary of the Invention

[0007] This application provides a method and device for processing smart contracts on a blockchain, which is beneficial to improving the security of smart contracts.

[0008] In a first aspect, a method for processing a smart contract of a blockchain is provided, comprising: obtaining a first syntax tree corresponding to a source contract; identifying a risk node in the first syntax tree, the risk node involving a risk operation; performing at least one of the following processing on the first syntax tree to obtain a second syntax tree: replacing a first risk node in the risk node with a first safety node, the first risk node involving a first risk operation, the first safety node involving a first safety operation, the first safety operation being used to replace the first risk operation; or, adding a permission detection condition to a second risk node in the risk node, the permission detection condition being used to determine the identity of the caller when a function indicated by the second risk node is called.

[0009] In an embodiment of the present application, processing the first syntax tree corresponding to the source contract is beneficial to improving the security of the smart contract. Specifically, by replacing the risky nodes in the first syntax tree with the corresponding safe nodes, risky operations can be replaced with corresponding safe operations, which is beneficial to reducing vulnerabilities in the contract and thus improving the security of the contract. Alternatively, additional permission detection conditions are added to the tree nodes involving access rights so that the contract needs to determine whether the caller's identity is legal during runtime, thereby improving the security of the contract operation and avoiding permission control loopholes.

[0010] At the same time, the solution of the embodiment of the present application helps reduce the processing required by users at the code level, simplifies the coding process, reduces usage costs, and improves development efficiency. Moreover, this can also lower the learning threshold for contract development, thereby improving the ease of use of the language.

[0011] Exemplarily, the first syntax tree may be generated based on the source contract, that is, the syntax tree of the source contract.

[0012] Alternatively, the first syntax tree may be obtained by processing the syntax tree of the source contract.

[0013] In combination with the first aspect, in certain implementations of the first aspect, performing at least one of the following processes on the first syntax tree further includes: when the risk node includes a third risk node, throwing exception indication information based on the third risk node.

[0014] In the solution of the embodiment of the present application, when a risk node is identified, an error may be reported to remind the user to take action.

[0015] In combination with the first aspect, in some implementations of the first aspect, the processing method is applied to a compiler.

[0016] In combination with the first aspect, in certain implementations of the first aspect, the processing method further includes: when the risk node includes a third risk node, refusing to pass the compilation process of the source contract.

[0017] In the solution of the embodiment of the present application, when certain risk nodes are identified, the compilation of the source contract can be refused. In this way, the contract cannot be deployed and run, avoiding the vulnerabilities that may be caused by these risk nodes from the source, thereby improving the security of the contract.

[0018] In combination with the first aspect, in certain implementations of the first aspect, the third risk node involves a second risk operation, the second risk operation belongs to a first risk set, and the first risk set includes risk operations that may cause uncertainty vulnerabilities in any scenario.

[0019] In combination with the first aspect, in certain implementations of the first aspect, the third risk node involves a second risk operation, the second risk operation belongs to a second risk set, the second risk set includes risk operations that may cause uncertainty vulnerabilities in some scenarios, the second risk operation satisfies the uncertainty condition corresponding to the second risk operation, and the uncertainty condition corresponding to the second risk operation is used to determine whether the second risk operation causes uncertainty vulnerabilities.

[0020] In combination with the first aspect, in certain implementations of the first aspect, the third risk node does not have an uncertainty annotation, or the processing method includes: when the risk node includes the third risk node and the third risk node has an uncertainty annotation, no exception indication information is thrown based on the third risk node.

[0021] In the solution of the embodiment of the present application, a mechanism for enabling or disabling the uncertainty vulnerability prevention function can be provided to the user, allowing the user to disable the vulnerability prevention mechanism, thereby avoiding the negative impact of the vulnerability prevention mechanism on language expression ability in certain scenarios.

[0022] In combination with the first aspect, in certain implementations of the first aspect, the first risk node in the risk node is replaced with the first safety node, including: according to the mapping relationship between multiple candidate risk operations and multiple candidate safety operations, the first risk node is replaced with the first safety node, the first risk operation belongs to multiple candidate risk operations, and the first safety operation belongs to multiple candidate safety operations.

[0023] In combination with the first aspect, in certain implementations of the first aspect, the processing method also includes: replacing the first initial node in the second syntax tree with a first target node, the first initial operation involved in the first initial node is related to the identity information in the first platform, the first replacement operation involved in the first target node is related to the identity information in the second platform, the second platform supports the deployment of the target contract, and the target contract is determined based on the source contract.

[0024] In the embodiments of the present application, smart contracts written in a source language can be converted into smart contracts written in other programming languages, which helps improve the portability of programming languages, or in other words, improves the portability of smart contracts and reduces migration costs. Specifically, operations related to identities in platform #2 are converted into operations related to identities in platform #3, which handles the differences in identity information between platforms #2 and #3, thereby facilitating the migration of smart contracts between different operating environments.

[0025] In combination with the first aspect, in certain implementations of the first aspect, replacing the first initial node in the second syntax tree with the first target node includes: replacing the first initial node with the first target node according to a mapping relationship between multiple candidate initial operations and multiple candidate replacement operations, the first initial operation belongs to multiple candidate initial operations, and the first replacement operation belongs to multiple candidate replacement operations.

[0026] In combination with the first aspect, in certain implementations of the first aspect, the processing method further includes: embedding a permission control code into the target contract, where the permission control code is used to describe the permission relationship corresponding to the identity information in the first platform.

[0027] For example, the permission control code can be embedded in the target contract in the form of comments.

[0028] In an embodiment of the present application, permission control code is embedded in the target contract, and users can modify and call the permission control code as needed, thereby realizing permission control in the smart contract, which is conducive to reducing migration costs.

[0029] In combination with the first aspect, in certain implementations of the first aspect, the processing method further includes: replacing the second initial node in the second syntax tree with a second target node, the second initial node corresponds to the first initial syntax element in the source language, the second target node corresponds to the first target syntax element in the target language, the source language is the programming language of the source contract, and the target language is the programming language of the target contract.

[0030] In an embodiment of the present application, converting the grammatical elements of the source language into the grammatical elements of the target language is conducive to realizing the conversion from the smart contract in the source language to the smart contract in the target language.

[0031] In combination with the first aspect, in certain implementations of the first aspect, replacing the second initial node in the second syntax tree with the second target node includes: replacing the second initial node with the second target node based on a mapping relationship between multiple candidate initial syntax elements and multiple candidate target syntax elements, the first initial syntax element belongs to multiple candidate initial syntax elements, and the first target syntax element belongs to multiple candidate target syntax elements.

[0032] The mapping relationship between multiple candidate initial grammatical elements and multiple candidate target grammatical elements is the mapping relationship between grammatical concepts in the source language and the target language.

[0033] In combination with the first aspect, in some implementations of the first aspect, the programming language used by the source contract is an internal domain-specific language with Java as the host language.

[0034] In combination with the first aspect, in certain implementations of the first aspect, the syntax of the programming language used by the source contract includes the syntax of the Java language and an extended syntax, the extended syntax is related to the field of smart contracts, and the extended syntax includes at least one of the following: keywords, data types, built-in variables, or built-in functions.

[0035] In the embodiments of this application, the extended syntax is relevant to the field of smart contracts. This allows the DSL in this embodiment of the application to focus on the smart contract field, improves the understandability of the language syntax, and thus improves the ease of use for smart contract development. Furthermore, the improved understandability of the language syntax helps lower the learning threshold for users, thereby reducing the generation of error codes and improving the user experience.

[0036] In combination with the first aspect, in some implementations of the first aspect, the built-in functions in the extended syntax include: a function for converting an object into a script object notation JSON string, and / or a function for converting a JSON string into an object.

[0037] In the embodiments of the present application, the extended syntax is more consistent with the coding habits of users in the smart contract field, simplifying the program development process, further improving usability, and facilitating a better user experience. In the smart contract field, conversion between JSON strings and objects is often necessary. The solution of the embodiments of the present application provides two built-in functions, obj2Json and json2Obj, which users can directly call to convert between JSON strings and objects. This simplifies the conversion process, better aligns with user coding habits, reduces the amount of manual code written by users, further improves usability, and thus facilitates a better user experience.

[0038] In combination with the first aspect, in certain implementations of the first aspect, the processing method also includes: obtaining a tag sequence of the source contract; converting the tag of the target keyword in the tag sequence into a Java annotation corresponding to the target keyword to obtain a processed tag sequence, where the target keyword belongs to a keyword in the extended grammar; generating a third syntax tree based on the processed tag sequence; replacing the third initial node in the third syntax tree with a grammar interface corresponding to the third initial node to obtain a first syntax tree, where the grammar interface corresponding to the third initial node is implemented based on the underlying call application program interface API of the first platform, the third initial node involves extended grammar, and the first platform supports the Java language.

[0039] In the solution of the embodiment of the present application, the extended grammar is processed to ensure that the extended grammar is compilable, thereby ensuring the usability of the language.

[0040] In a second aspect, a method for processing a smart contract of a blockchain is provided, including: obtaining a fourth syntax tree corresponding to a source contract; replacing a first initial node in the fourth syntax tree with a first target node, wherein a first initial operation involved in the first initial node is related to identity information in a first platform, and a first replacement operation involved in the first target node is related to identity information in a second platform, wherein the second platform supports the deployment of a target contract, and the target contract is determined based on the source contract.

[0041] In combination with the second aspect, in certain implementations of the second aspect, the processing method also includes: replacing the first initial node in the fourth syntax tree with a first target node, including: replacing the first initial node with a first target node according to a mapping relationship between multiple candidate initial operations and multiple candidate replacement operations, the first initial operation belongs to multiple candidate initial operations, and the first replacement operation belongs to multiple candidate replacement operations.

[0042] In combination with the second aspect, in certain implementations of the second aspect, the processing method further includes: embedding a permission control code into the target contract, where the permission control code is used to describe the permission relationship corresponding to the identity information in the first platform.

[0043] In combination with the second aspect, in certain implementations of the second aspect, the processing method also includes: replacing the second initial node in the fourth syntax tree with a second target node, the second initial node corresponds to the first initial syntax element in the source language, the second target node corresponds to the first target syntax element in the target language, the source language is the programming language of the source contract, and the target language is the programming language of the target contract.

[0044] In combination with the second aspect, in certain implementations of the second aspect, replacing the second initial node in the fourth syntax tree with the second target node includes: replacing the second initial node with the second target node according to a mapping relationship between multiple candidate initial syntax elements and multiple candidate target syntax elements, the first initial syntax element belongs to multiple candidate initial syntax elements, and the first target syntax element belongs to multiple candidate target syntax elements.

[0045] In combination with the second aspect, in certain implementations of the second aspect, the processing method also includes: obtaining a first syntax tree corresponding to the source contract; identifying a risk node in the first syntax tree, the risk node involving a risk operation; performing at least one of the following processing on the first syntax tree, and using the processed first syntax tree as the fourth syntax tree: replacing the first risk node in the risk node with a first safety node, the first risk node involving a first risk operation, the first safety node involving a first safety operation, and the first safety operation being used to replace the first risk operation; adding a permission detection condition to the second risk node in the risk node, the permission detection condition being used to determine the identity of the caller when the function indicated by the second risk node is called, or in the case where the risk node includes a third risk node, throwing exception indication information based on the third risk node.

[0046] On the third aspect, a method for processing smart contracts of a blockchain is provided, including: obtaining a tag sequence of a source contract, the programming language used by the source contract is an internal domain-specific language with Java as the host language, the syntax of the programming language used by the source contract includes the syntax of the Java language and an extended syntax, the extended syntax is related to the smart contract field, and the extended syntax includes at least one of the following: keywords, data types, built-in variables or built-in functions; converting the tags of the target keywords in the tag sequence into Java annotations corresponding to the target keywords to obtain a processed tag sequence, the target keywords belong to the keywords in the extended syntax; generating a third syntax tree based on the processed tag sequence; replacing the third initial node in the third syntax tree with the syntax interface corresponding to the third initial node to obtain the first syntax tree, the syntax interface corresponding to the third initial node is implemented based on the underlying call application program interface API of the first platform, the third initial node involves extended syntax, and the first platform supports Java language.

[0047] In combination with the third aspect, in some implementations of the third aspect, the built-in functions in the extended syntax include: a function for converting an object into a script object notation Json string, and / or a function for converting a Json string into an object.

[0048] In a fourth aspect, a method for processing smart contracts on a blockchain is provided, comprising: displaying a code editing interface; receiving input smart contract code, the code being based on the syntax and extended syntax of the Java language, the extended syntax being related to the field of smart contracts, and the extended syntax including at least one of the following: keywords, data types, built-in variables, or built-in functions.

[0049] In the fifth aspect, a processing device for smart contracts of a blockchain is provided. The processing device may include a module corresponding to each of the methods / operations / steps / actions described in the first aspect or the fourth aspect. The module may be a hardware circuit, software, or a combination of hardware circuit and software.

[0050] It should be understood that the expansion, limitation, explanation and description of the relevant content in the above-mentioned first aspect also apply to the same content in the second to fifth aspects.

[0051] In a sixth aspect, a computing device cluster is provided, comprising at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the method of any one of the implementations of aspects 1 to 4.

[0052] In a seventh aspect, a computer-readable medium is provided, comprising computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method in any one of the implementations of the first to fourth aspects.

[0053] In an eighth aspect, a computer program product comprising instructions is provided. When the instructions are executed by a computing device cluster, the computing device cluster executes the method in any one of the implementations of the first to fourth aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] FIG1 is a schematic flow chart of a method for processing a smart contract according to an embodiment of the present application;

[0055] FIG2 is a schematic flow chart of another method for processing a smart contract according to an embodiment of the present application;

[0056] FIG3 is a schematic block diagram of the architecture of a precompiler according to an embodiment of the present application;

[0057] FIG4 is a schematic diagram of a workflow of a precompiler according to an embodiment of the present application;

[0058] FIG5 is a schematic flow chart of another method for processing a smart contract according to an embodiment of the present application;

[0059] FIG6 is a schematic flow chart of another method for processing a smart contract according to an embodiment of the present application;

[0060] FIG7 is a schematic diagram of a smart contract template according to an embodiment of the present application;

[0061] FIG8 is a schematic block diagram of another precompiler architecture according to an embodiment of the present application;

[0062] FIG9 is a schematic diagram of the workflow of another precompiler according to an embodiment of the present application;

[0063] FIG10 is a schematic diagram of a workflow of a grammar parsing module according to an embodiment of the present application;

[0064] FIG11 is a schematic diagram of a workflow of a vulnerability prevention module according to an embodiment of the present application;

[0065] FIG12 is a schematic diagram of a workflow of a platform transplantation module according to an embodiment of the present application;

[0066] FIG13 is a schematic block diagram of an operating environment of a smart contract according to an embodiment of the present application;

[0067] FIG14 is a schematic block diagram of a smart contract processing device according to an embodiment of the present application;

[0068] FIG15 is a schematic block diagram of a computing device according to an embodiment of the present application;

[0069] FIG16 is a schematic block diagram of a computing device cluster according to an embodiment of the present application;

[0070] FIG17 is a schematic block diagram of another computing device cluster according to an embodiment of the present application. DETAILED DESCRIPTION

[0071] The terms used in the following embodiments are for the purpose of describing specific embodiments only and are not intended to limit the present application. As used in the specification and appended claims of this application, the singular expressions "a," "an," and "the" are intended to include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one," "at least one," and "one or more" refer to one, two, or more. "First," "second," and various numerical designations are merely distinctions made for ease of description and are not intended to limit the scope of the embodiments of this application. "And / or" is used to describe the corresponding relationship between corresponding objects, indicating that three relationships can exist. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist, where A and B can be singular or plural. The character " / " generally indicates that the objects associated with each other are in an "or" relationship. The order of the sequence numbers of the processes below does not imply a sequence of execution. The execution order of each process should be determined by its function and inherent logic and should not constitute any limitation on the implementation process of the embodiments of this application. For example, in the embodiments of the present application, words such as "301", "401", and "501" are merely identifiers for the convenience of description and do not limit the order of executing the steps.

[0072] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. In this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described in this application as "exemplary" or "for example" should not be interpreted as being more preferred or more advantageous than other embodiments or design. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete way. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized. In the embodiments of the present application, descriptions such as "when...", "in the case of...", "if" and "if" all mean that the device will perform corresponding processing under certain objective circumstances, and do not limit the time, nor do they require the device to perform judgment actions when implemented, nor do they mean that there are other limitations.

[0073] In this application, "used to indicate" can include being used for direct indication and being used for indirect indication. When describing that a certain indication information is used to indicate A, it can include that the indication information directly indicates A or indirectly indicates A, and it does not mean that the indication information must carry A.

[0074] In order to help those skilled in the art better understand the technical solutions of the present application, some terms that may be involved in the embodiments of the present application are explained below.

[0075] (1) Blockchain;

[0076] Blockchain is a distributed data ledger that is decentralized, tamper-proof, traceable, and jointly maintained by multiple parties. It achieves trusted distributed storage of data by integrating multiple technologies such as peer-to-peer (P2P) protocols, asymmetric encryption, and consensus mechanisms.

[0077] (2) Smart contracts;

[0078] A smart contract is a code program that runs synchronously on multiple nodes of a distributed ledger and can be executed automatically without relying on a central authority.

[0079] (3) Hyperledger fabric (HF);

[0080] Hyperledger is an open source framework for consortium chains. It features good performance, a highly modular and configurable architecture, comprehensive member management and access control, and is suitable for building flexible and high-quality enterprise consortium blockchain systems for multiple industries.

[0081] (4) The programming language of the smart contract;

[0082] Smart contract programming languages ​​can be divided into two categories: domain specific languages ​​(DSLs) and general-purpose programming languages.

[0083] A domain-specific language is a programming language that focuses on a specific domain but has limited expressive power. DSLs can be categorized into three types: external DSLs, internal DSLs, and language workbenches.

[0084] External DSLs, also known as independent DSLs, have domain-specific syntax and independent compilers. They are independent of any other language and have their own independent interpreter or compiler tools for lexical analysis, syntax analysis, and code generation. For example, the Solidity language on the Ethereum platform has domain-specific syntax for smart contracts and an independent compiler.

[0085] The process of implementing an external DSL includes defining the syntax and semantics of the language; constructing a compiler to parse the language into machine bytecode; and executing it in a closed environment, such as an adapted virtual machine. External DSLs focus on key concepts within a specific domain, abstracting some implementation and technical details and exposing only the truly essential information. As a result, the syntax is typically more concise, easier to understand and analyze, and allows developers to better communicate with domain experts, improving productivity. Furthermore, DSLs decouple domain logic from technology, allowing them to evolve independently. Domain logic has its own value and should be preserved, making the investment in writing code using a DSL even more valuable.

[0086] External DSLs have some inherent disadvantages. First, it's difficult to achieve both ease of use and security. Turing-complete DSLs, such as Solidity, enable the development of logically complex smart contracts, but they suffer from significant security disadvantages. Turing-incomplete DSLs, such as Vyper, mitigate security issues by removing some dangerous syntax, but this also limits the expressive power of the language itself. Second, due to the relatively limited application scenarios of DSLs, they often have many design limitations, which can hinder development. For example, they lack common method libraries and standard interfaces, and additional features such as error reporting and logging, hindering development efficiency. Third, they lack community resources. Smart contracts are not widely used in industry. Even for Solidity, the most popular smart contract DSL, the number of relevant code repositories available on GitHub is approximately 100 times less than that of Java. This lack of community resources means a high learning threshold, hindering problem-solving when encountering difficulties during contract development. Fourth, the current smart contract DSL ecosystem is not perfect, for example, there is a lack of a complete interactive integrated development environment (IDE), debugger, and debugging tools.

[0087] Internal DSLs, also known as embedded DSLs, use an existing programming language as the host language and extend it with domain-specific syntax and semantics. The host language is selected and syntactically extended by the internal DSL. Implementing an internal DSL eliminates the need to design a language grammar and compiler from scratch. Instead, the host language can be used to analyze and model domain-specific problems, integrating with the host language's compilation mechanisms. The difference between internal and external DSLs lies primarily in their implementation principles; the resulting differences are minimal.

[0088] The language workbench (LWB) achieves a higher level of abstraction through models or graphical methods, and then automatically converts models to code through code generation. LWB enables developers to build a set of syntax and semantics with minimal effort, thereby supporting efficient program development. LWB constitutes a multi-paradigm and language-oriented programming environment to address challenges in software engineering. LWB's functions are mainly divided into six aspects, namely, it must support the symbols, semantics and editors of the defined language and its models, support model verification, testing and debugging of models and languages, and support the combination of multiple defined languages ​​in different aspects. LWB is generally used to define model and language rules for the application domain of key software components, then use models to describe one or more components, and then convert the models into component code or other artifacts through code generation. If the correctness of code conversion can be guaranteed, the productivity and quality of software development can be improved.

[0089] General-purpose programming languages ​​can be divided into two categories. The first category directly expands upon the native language and encapsulates the APIs for underlying blockchain and smart contract operations. The second category modifies the native language to make it more suitable for the smart contract field.

[0090] The principle behind native general-purpose languages ​​supporting smart contract development is to extend and encapsulate third-party libraries related to the underlying blockchain to provide APIs for operating smart contracts. Using general-purpose languages ​​for contract development offers many inherent advantages. First, general-purpose languages ​​have a wider user base, reducing the learning curve for developers from other fields to enter smart contract development and accelerating the adoption of blockchain solutions across various sectors. Second, general-purpose languages ​​are often accompanied by a rich ecosystem of tools and extensive community resources. Finally, general-purpose languages ​​have numerous supporting libraries and offer many common features, providing general solutions to typical programming problems and making them easily applicable to smart contract development. For example, Go, Java, and JavaScript provide relevant third-party libraries to support smart contract development on the HF platform. However, native general-purpose languages ​​are not specifically designed for smart contracts, and therefore lack adaptability when used in smart contract scenarios. They also suffer from the following shortcomings: First, the syntax of general-purpose languages ​​is more verbose and complex than that of DSLs, and they require the inclusion of numerous third-party libraries during development, increasing the complexity of programming. Second, while generally secure by design, general-purpose languages ​​still struggle to fully meet the specific security requirements of smart contract scenarios, such as the potential for security vulnerabilities such as uncertainty. Third, as a general language, many of the complex functions it supports are redundant for smart contract scenarios, which can easily lead to some security risks and may cause a waste of space resources.

[0091] Due to the numerous shortcomings of developing smart contracts using native general-purpose languages, some researchers have been developing adaptations based on native languages ​​to address the specific characteristics of the smart contract field. Generally speaking, adapted languages ​​are a subset of native languages. Existing work primarily focuses on adapting Java. For example, Hotmoka only allows the use of whitelisted methods and libraries from the standard Java library to prevent inconsistent contract execution results caused by Java's non-determinism. Corda provides a minimal set of Java libraries for contract verification. NEO similarly ensures maximum security by restricting the use of Java libraries. In reality, many Java support libraries are non-deterministic. For most blockchains, this non-determinism can hinder the ability of nodes to reach consensus on contract execution results, leading to forks in the blockchain network. In HF, transactions are rejected if code execution is non-deterministic. Existing adaptations retain most of the advantages of general-purpose languages ​​while addressing their common non-determinism and eliminating unnecessary mechanisms in native languages ​​specific to smart contract scenarios. However, current adaptations to general-purpose languages ​​primarily focus on reducing their functionality, leaving limited room for improvement.

[0092] (5) Application programming interface (API);

[0093] API is the code provided by the operating system or program library for application programs to call and use.

[0094] (6) Abstract syntax tree (AST);

[0095] AST is an abstract representation of the grammatical structure of source code. It represents the grammatical structure of a programming language in a tree-like form, where each node in the tree represents a structure in the source code.

[0096] (7) Concept mapping;

[0097] Concept mapping is the process of associating syntactic elements of one programming language with corresponding syntactic elements of another language.

[0098] (8) Procedural uncertainty;

[0099] A program that contains nondeterminism may produce different outputs when run twice when given the same input.

[0100] (9) Uncertainty loopholes;

[0101] A nondeterministic vulnerability is a vulnerability that causes program uncertainty. In blockchain, nondeterministic vulnerabilities can cause inconsistent understanding of ledger data among nodes in the network, leading to security issues such as forks.

[0102] (10) Permission access control vulnerabilities;

[0103] When unauthorized users in an application are able to access functions or variables they shouldn't, this vulnerability arises. This vulnerability is particularly critical in the smart contract space, as smart contracts are difficult to modify once they're on-chain.

[0104] Blockchain provides a trusted channel for information and value exchange across untrusted networks, effectively addressing the data falsification inherent in traditional transactions. Smart contracts are executable code that can be deployed on the blockchain, automatically executing contracts on behalf of all parties involved without relying on a central authority. As smart contract technology continues to evolve, its supported scenarios are expanding, encompassing a wide range of application areas, including finance, supply chain, the Internet of Things, and public administration. At the same time, the business logic required to be processed is becoming increasingly complex, exposing a series of limitations in smart contract languages.

[0105] Writing contracts in a language that's easy to use, learn, and understand is a common desire among developers of all levels of experience. However, existing programming languages ​​fail to meet this need. DSLs in the smart contract field offer advantages such as concise syntax, ease of understanding, and ease of analysis, but they also have some disadvantages. For example, external DSLs have inherent disadvantages. First, it's difficult to achieve both ease of use and security. Turing-complete DSLs, such as Solidity, enable the development of logically complex smart contracts, but suffer from significant security disadvantages. Turing-incomplete DSLs, such as Vyper, mitigate security issues by removing dangerous syntax, but this also limits the expressive power of the language itself. Second, due to their relatively limited application scenarios, DSLs often have numerous design limitations, creating development inconveniences. For example, they lack common method libraries and standard interfaces, and additional features such as error reporting and logging, hindering development efficiency. Third, they suffer from limited community resources. Smart contracts are not widely used in industry. Even for Solidity, the most popular smart contract DSL, the number of repositories available on GitHub is approximately 100 times smaller than that of Java. This lack of community resources means a high learning curve, hindering problem-solving when encountering difficulties during contract development. Fourthly, the current smart contract DSL ecosystem is incomplete, lacking, for example, a comprehensive integrated development environment (IDE), debugger, and debugging tools.

[0106] Current programming languages ​​for smart contracts lack usability and user satisfaction. DSLs for smart contracts lack common libraries and standard interfaces, and additional features like error reporting. Furthermore, the programming language ecosystem is incomplete, with limited community resources and documentation, making it difficult to support efficient and standardized smart contract development.

[0107] Therefore, how to improve the usability of smart contract programming languages ​​has become an urgent problem to be solved.

[0108] In view of this, embodiments of the present application provide a design framework for a domain-specific language (DoS) developed for the smart contract field. This design framework includes an extended syntax definition and a precompiler. Specifically, the Domain-Specific Language (DoS) proposed in embodiments of the present application is an internal DSL using Java as the host language. This internal DSL expands the syntax definition of the smart contract field based on Java, enhances the definition of the smart contract field, and thus improves the usability of the programming language in the smart contract field. The precompiler can be used to perform syntax parsing on smart contracts developed using the DSL in embodiments of the present application to ensure that the extended syntax is compilable.

[0109] Figure 1 shows a method for processing a smart contract provided by an embodiment of the present application. The method 100 shown in Figure 1 can be executed by a smart contract development platform or development tool.

[0110] Method 100 is applied to the development phase of a smart contract. The programming language for smart contracts is an internal DSL using Java as the host language. The internal DSL provided in this embodiment of the application can be called JSmarter. Specifically, JSmarter is an internal DSL targeting the smart contract field using Java as the host language.

[0111] JSmarter's syntax includes the Java language syntax and an extended syntax. The extended syntax is related to the field of smart contracts.

[0112] The extended syntax is related to the field of smart contracts. It can be understood that the extended syntax is used to indicate concepts in the field of smart contracts or to implement operations in the field of smart contracts.

[0113] In the embodiments of the present application, a smart contract may also be referred to as a contract.

[0114] As shown in FIG. 1 , method 100 may include the following steps.

[0115] 110, displaying the code editing interface.

[0116] 120, receiving the input smart contract code, which is based on the syntax and extended syntax of the Java language.

[0117] The user can use JSmarter to write the code of the smart contract. The smart contract code input by the user received in step 120 is the code written based on the syntax of JSmarter.

[0118] The extended syntax in JSmarter includes at least one of the following types: keywords, data types, built-in variables, or built-in functions.

[0119] Exemplarily, the extended keywords include keywords related to the field of smart contracts.

[0120] Optionally, the extended keywords include at least one of the following: declaring a contract, declaring a structure, declaring an event, triggering an event, modifying a function that can read the ledger, or modifying a function that can write to the ledger, etc.

[0121] Exemplarily, the extended data types include data types in the field of smart contracts.

[0122] Optionally, the extended data type includes ledger records.

[0123] Exemplarily, the extended built-in variables include variables in the smart contract field.

[0124] Optionally, the extended built-in variable includes at least one of the following: function call information, transaction information, or a logger, etc.

[0125] For example, the extended built-in functions are used to perform operations in the smart contract field.

[0126] For example, the input code may include calls to built-in functions of the extension.

[0127] Optionally, the extended built-in function may include a function for converting an object into a JavaScript object notation (JSON) string, and / or a function for converting a JSON string into an object. Script object notation is JS object notation.

[0128] For example, the input code may include a call to a first built-in function, which belongs to an extended built-in function. The first built-in function is a function for converting an object into a JSON string, or a function for converting a JSON string into an object.

[0129] As an example, the extended syntax may include one or more of the syntaxes in Table 1. For example, as shown in Table 1, based on the native Java syntax, JSmarter extends 6 keywords, 1 data type, 3 built-in variables, and 10 built-in functions for the smart contract field.

[0130] Table 1

[0131] It should be understood that the extended syntax shown in Table 1 is only an example and does not limit the solutions of the embodiments of the present application.

[0132] In the solution of the embodiment of the present application, JSmarter uses Java as the host language. Java performs well in traditional application fields, which can reduce the restrictions of the host language on JSmarter.

[0133] Specifically, Java offers excellent usability in traditional application areas, significantly lowering the learning curve for users by using it as a host language. Furthermore, Java is the most commonly used programming language among developers in open source projects, boasting a vast user base and a robust community ecosystem. Java-based internal DSLs can be developed using the existing Java toolchain, reducing development complexity. Furthermore, many blockchain platforms support the development of smart contracts in Java.

[0134] Smart contracts written using the internal DSL are also legitimate host language programs, allowing the solution in this application to be developed using the standard Java toolchain. This lowers the learning curve for users, reduces the generation of erroneous code, and improves the user experience. Furthermore, JSmarter leverages the Java language's vast user base and mature supporting tools to provide general solutions to common programming problems.

[0135] In the embodiments of this application, the extended syntax in JSmarter is relevant to the smart contract field, covering concepts unique to that field, such as account operations, account addresses, and endorsement policies. This allows the DSL in the embodiments of this application to focus on the smart contract field, improving the understandability of the language syntax and thus enhancing the ease of use for smart contract development. Furthermore, the improved understandability of the language syntax helps lower the learning threshold for users, thereby reducing the occurrence of error codes and improving the user experience.

[0136] At the same time, in the solution of the embodiment of the present application, the extended syntax is more in line with the coding habits of users in the field of smart contracts, simplifies the process of program development, further improves ease of use, and is conducive to improving user experience. For example, the built-in functions of JSmarter provide functions commonly used in the field of smart contracts, which is conducive to reducing the amount of handwritten code by users, thereby improving development efficiency. For example, in the field of smart contracts, it is often necessary to implement conversions between json strings and objects. The solution of the embodiment of the present application provides two built-in functions, obj2Json and json2Obj. Users can directly call these two functions to implement conversions between json strings and objects, simplifying the conversion process, and being more in line with the coding habits of users, further improving ease of use, and thus helping to improve user experience. The solution of the embodiment of the present application can reduce the amount of handwritten code by more than 40%, and improve development efficiency by more than 20%.

[0137] Furthermore, this will help more users participate in the development of smart contract applications, which will be beneficial to the ecological construction of blockchain and smart contracts, thereby further promoting the expansion of business and application areas.

[0138] Figure 2 shows a smart contract processing method provided in an embodiment of the present application, which can process smart contracts developed using JSmarter to ensure that the smart contracts can be compiled.

[0139] The method 200 shown in Figure 2 can be executed by a precompiler. The precompiler can be used to process the source contract and output an AST, or output a target contract.

[0140] Processing the source contract means processing the source contract code. The source contract code can also be called the source code of the source contract. The programming language of the source contract is JSmarter. The source contract can be represented as a JSmarter character stream. The programming language of the source contract can be simply referred to as the source language.

[0141] Outputting the target contract can be understood as outputting the target contract's character stream, or in other words, outputting the target contract's code. The target contract's character stream is the character stream of the target contract's programming language. The target contract's programming language can be referred to as the target language.

[0142] For example, the programming language of the target contract may be Java. In this case, the target contract can be represented as a character stream in Java. The input of the precompiler can be a character stream in JSmarter, and the output of the precompiler can be a character stream in Java.

[0143] For example, the target contract can be written in Solidity. In this case, the target contract can be represented as a Solidity character stream. The precompiler input can be a JSmarter character stream, and the precompiler output can be a Solidity character stream.

[0144] It should be understood that the above is merely an example, and the programming language of the target contract can also be other programming languages, which is not limited in the present embodiment. For ease of description, method 200 is mainly described using Java as the target language. For cases where the target language is other programming languages, please refer to method 600 below, which is not described in detail here.

[0145] Exemplarily, the precompiler may be integrated into the compiler as a functional module of the compiler.

[0146] Taking Java as the target language as an example, the precompiler can be integrated into the Java compiler as a functional module of the Java compiler.

[0147] Exemplarily, the precompiler may be a device independent of the compiler, and the output of the precompiler may serve as the input of the compiler.

[0148] For example, if the target language is Java, the precompiler outputs the target contract, which is a character stream in the Java language. The Java compiler parses the target contract and outputs the corresponding bytecode. The bytecode can be deployed on the blockchain platform.

[0149] As described above, by adopting the solution of the embodiment of the present application, the precompiler can process the source contract using JSmarter into a form that can be parsed by the existing compiler, so that the existing compiler can be directly reused, which is conducive to reducing development costs.

[0150] It should be understood that the above is only an example and does not limit the operating environment of the target contract. The operating environment of the target contract may include an internal environment and an external environment.

[0151] The internal environment refers to the inside of the blockchain platform, or in other words, the internal environment includes the nodes in the blockchain platform.

[0152] As a possible example, the character stream of the target contract can be deployed as an internal chaincode on a node within the blockchain platform, and directly called by the node within the blockchain platform after compilation.

[0153] The external environment refers to other operating environments outside the blockchain platform, for example, cloud environments such as Kubernetes.

[0154] As another possible example, the character flow of the target contract can be deployed as an external chain code that is independent of the blockchain platform and in an environment other than the blockchain platform. For example, the external chain code can be run as a service.

[0155] For example, the compilation of external chaincodes and the configuration and construction of related services can be implemented through the blockchain platform's middleware. Taking Kubernetes as an example, this middleware can include HF's external builder and launcher. When the target contract needs to be called, the peer node can start and call the external chaincode through the middleware.

[0156] The blockchain platform in the embodiments of this application can be used to deploy smart contracts. However, this does not limit smart contracts to being deployed only on blockchain platforms. For example, blockchain platform #A can be used to deploy smart contract #a. In this case, smart contract #a can be deployed on blockchain platform #A. Alternatively, smart contract #a can be deployed in external environment #A, which can rely on blockchain platform #A's middleware to call smart contract #a.

[0157] For the sake of ease of description, the embodiments of this application mainly use the operating environment of the smart contract as an internal environment for illustration, and do not limit the solutions of the embodiments of this application.

[0158] FIG3 shows a schematic diagram of the architecture of a precompiler according to an embodiment of the present application.

[0159] As shown in Figure 3, the precompiler 300 may include a syntax parsing module 310. The syntax parsing module 310 acts in the syntax parsing stage.

[0160] For example, as shown in Figure 3 , the source contract is input into parsing module 310. Parsing module 310 can be used to parse the source contract to generate an AST. Parsing the source contract involves parsing the source contract's code. Specifically, parsing module 310 can be used to perform lexical analysis and syntactic analysis on the source code to generate AST#2.

[0161] Furthermore, precompiler 300 may optionally include a code generation module 330. Code generation module 330 operates during the code generation phase. Code generation module 330 may be used to generate a target contract based on AST#2, i.e., to generate a character stream in the target language, such as the Java character stream in FIG3 .

[0162] Exemplarily, the method 200 shown in FIG. 2 may be executed by the precompiler 300 .

[0163] As shown in Figure 2, method 200 includes the following steps: Step 210 and Step 220 can be considered as the lexical analysis stage, and Step 230 and Step 240 can be considered as the syntax analysis stage.

[0164] 210. Get the token sequence of the source contract.

[0165] Exemplarily, the token sequence of the source code may be generated by the syntax parsing module 310 .

[0166] The syntax parsing module 310 can scan the source code to identify each word in the source code and generate a token sequence of the source code.

[0167] Alternatively, the token sequence of the source code can be generated by other modules.

[0168] For example, a lexical analyzer in a Java compiler can scan the source code to generate a token sequence of the source code. The syntax parsing module 310 can obtain the token sequence of the source code from the lexical analyzer.

[0169] The embodiment of the present application does not limit the method for obtaining the token sequence of the source code.

[0170] 220, convert the token of the target keyword in the token sequence into a Java annotation corresponding to the target keyword to obtain a processed token sequence. The target keyword is an extended keyword.

[0171] In step 220, the token sequence of the source code is parsed to identify the token of the target keyword. If the token sequence of the source code includes the token of the target keyword, the token of the target keyword is converted into a corresponding Java annotation.

[0172] Exemplarily, step 220 may be performed by the syntax parsing module 310 .

[0173] For example, as shown in Figure 4, the syntax parsing module can identify the token of the target keyword and generate the corresponding Java annotation.

[0174] For example, the Java annotations corresponding to some of the expanded keywords in Table 1 are shown in Table 2. The keywords shown in Table 2 can be used as target keywords. For example, if a token for the keyword "contract" in Table 2 is identified in the token sequence, it is converted to the corresponding Java annotation "@Contact".

[0175] Table 2

[0176] Step 220 is an optional step. If the source code does not include the target keyword, for example, the source code may not use the extended keyword, then step 220 may not be performed.

[0177] 230, get AST#1.

[0178] In the case that the source code does not include the target keyword, AST# 1 may be generated based on the token sequence of the source code obtained in step 210 .

[0179] If the source code includes the target keyword, AST#1 can be generated based on the processed token sequence obtained in step 220. In this case, AST#1 can be used as an example of the third syntax tree. For ease of description, the embodiments of this application mainly use the processed token sequence as an example, and do not limit the solutions of the embodiments of this application.

[0180] Exemplarily, AST# 1 may be generated by the syntax parsing module 310 .

[0181] For example, the syntax parsing module 310 may generate AST#1 based on the processed token sequence.

[0182] Alternatively, AST#1 may be generated by other modules.

[0183] For example, a syntax analyzer in a Java compiler may generate AST#1 based on the processed token sequence, and the syntax parsing module 310 may obtain AST#1 from the syntax analyzer.

[0184] 240. Replace tree node #1 (an example of the third initial node) in AST #1 with the grammar interface corresponding to tree node #1 to obtain AST #2. Tree node #1 involves the extended grammar. In other words, tree node #1 is a node corresponding to the extended grammar. The grammar interface corresponding to tree node #1 is implemented based on the underlying call API of blockchain platform #1. Blockchain platform #1 supports the Java language.

[0185] In the embodiment of the present application, the tree nodes in the AST may also be referred to as nodes.

[0186] For example, blockchain platform #1 can be used to deploy a Java-based smart contract. If the target contract is a Java string, blockchain platform #1 can be used to deploy the target contract. For example, the target contract is compiled into bytecode and then deployed to blockchain platform #1.

[0187] In this embodiment of the present application, blockchain platform #1 may also be referred to as platform #1.

[0188] Tree node #1 relates to the extended grammar, i.e., tree node #1 belongs to the node corresponding to the extended grammar. Tree node #1 can be any tree node among the nodes corresponding to the extended grammar. The number of tree nodes #1 can be one or more, and the embodiment of the present application does not limit the number of tree nodes.

[0189] In step 240, the tree nodes in AST#1 that involve the extended syntax can be mapped to the defined syntax interface implementation. For example, the tree nodes in AST#1 that involve the Java annotations generated in step 220 (i.e., the Java annotations corresponding to the target keywords), the tree nodes that involve keywords replaced with other extensions other than Java annotations, the tree nodes that involve extended data types, the tree nodes that involve built-in variables, and the tree nodes that involve built-in functions are mapped to the defined syntax interface implementation. The syntax interface can be a syntax interface defined in the precompiler that fully matches the corresponding tree node.

[0190] For example, blockchain platform #1 can be the HF platform. The HF platform supports the Java language. The defined syntax interface can be implemented by the API provided by the HF platform.

[0191] In step 240, the tree nodes in AST#1 are traversed to identify the tree nodes in AST#1 that involve the extended grammar and map them to the corresponding grammar interface. After all tree nodes are traversed, AST#2 is output.

[0192] Exemplarily, step 240 may be performed by the syntax parsing module 310 .

[0193] For example, as shown in FIG4 , the grammar parsing module 310 performs node recognition in AST# 1 to identify the tree nodes of the grammar to be extended and maps them to the grammar interface.

[0194] Table 3 shows the mapping relationship between the extended syntax shown in Table 1 (processing objects in Table 3) and the syntax interface implemented based on the API provided by the HF platform.

[0195] Table 3

[0196] The tree node involving the Java annotation corresponding to the target keyword can be understood as the tree node modified by the Java annotation corresponding to the target keyword.

[0197] If all the extended keywords in the source contract are target keywords, the nodes corresponding to the extended keywords in AST#1 are the tree nodes modified by the Java annotations corresponding to the target keywords in AST#1.

[0198] If the extended keywords in the source contract include other extended keywords in addition to the target keyword, the nodes corresponding to the extended keywords in AST#1 may include tree nodes modified by the Java annotation corresponding to the target keyword and nodes corresponding to the other extended keywords. For example, the source contract includes the extended keywords in Table 1, that is, the extended keywords in the source contract include: event, emit, contract, struct, view, and payable. For example, as shown in Table 3, the target keywords in the source contract may include contract, struct, view, and payable. Other extended keywords in the source contract may include even and emit.

[0199] Furthermore, if AST#1 includes tree nodes modified by Java annotations corresponding to target keywords, the corresponding tree nodes can be added, deleted, or modified to make the tree nodes comply with the contract declaration specifications of blockchain platform #1.

[0200] For example, as shown in FIG4 , the syntax parsing module 310 may process the Java annotations, for example, adding, deleting or modifying the corresponding tree nodes.

[0201] In this way, the tree nodes corresponding to the extended syntax in AST#1 can be converted into the API provided by blockchain platform#1.

[0202] In the above operations, the precompiler 300 can automatically and synchronously add related import dependencies.

[0203] Furthermore, the method 200 may further include step 250 .

[0204] 250. Generate the target contract based on AST#2, that is, generate a character stream in the target language.

[0205] Exemplarily, step 250 may be performed by the code generation module 330 .

[0206] Optionally, the target language may be Java. In this case, the code generation module 330 may generate a character stream of Java based on AST#2, ie, the target contract.

[0207] In this way, the generated Java language character stream can be compiled by the existing Java compiler and then deployed on the blockchain platform, which helps reduce development costs.

[0208] The target language may also be other programming languages. In the case where the target language is other programming languages, the method for generating the target contract may refer to method 600 in the following text and will not be described in detail here.

[0209] In the solution of the embodiment of the present application, a precompiler is provided for JSmarter to process the extended grammar, which can ensure that the extended grammar is compilable, thereby ensuring the usability of the language.

[0210] In addition, the precompiler can process the source contract using JSmarter into a form that can be parsed by existing compilers, so that the existing compilers can be directly reused, which helps reduce development costs.

[0211] In recent years, vulnerabilities related to smart contracts have emerged one after another, posing security risks to higher-level applications. Insecure smart contracts can undermine the stability of the blockchain and infringe on the security of user assets. Furthermore, compared to other programs, smart contracts deployed on the blockchain are difficult to modify. Once these vulnerabilities are exploited, they can cause significant losses. Therefore, improving the security of smart contracts has become a pressing issue.

[0212] In view of this, an embodiment of the present application provides a method for processing smart contracts, which is conducive to identifying common vulnerabilities in the field of smart contracts, such as uncertainty vulnerabilities or reentrancy vulnerabilities, and improving the security of the language.

[0213] Figure 5 shows a schematic flow chart of another method for processing smart contracts according to an embodiment of the present application. The method 500 shown in Figure 5 can also be regarded as a method for preventing vulnerabilities in the field of smart contracts.

[0214] Exemplarily, the method 500 may be executed by a vulnerability prevention device.

[0215] The vulnerability prevention device can also be deployed in other devices as a functional module of the other devices. In this case, the vulnerability prevention device can also be called a vulnerability prevention module.

[0216] Exemplarily, the vulnerability prevention module may be deployed in a compiler.

[0217] Exemplarily, the vulnerability prevention module may be deployed in the precompiler 300 of the embodiment of the present application. For example, the precompiler 300 may include a syntax parsing module 310 and a vulnerability prevention module 320. The vulnerability prevention module 320 may act in the semantic analysis stage.

[0218] The solution of the embodiment of the present application can be applied to the compiler or precompiler 300, which is beneficial to avoid vulnerabilities from the source, thereby improving the security of the programming language, or in other words, improving the security of smart contracts.

[0219] As shown in FIG. 5 , method 500 may include the following steps.

[0220] 510. Obtain AST#4 (an example of the first syntax tree) corresponding to the source contract.

[0221] As a possible implementation method, AST#4 corresponding to the source contract can be the AST of the source contract.

[0222] For example, AST#4 can be parsed by a compiler. For example, if the source contract is written in Java, the compiler can be a Java compiler. For another example, if the source contract is written in Solidity, the compiler can be a Solidity compiler.

[0223] As another possible implementation, AST#4 can be obtained by processing the AST of the source contract.

[0224] Exemplarily, the AST#4 may be the AST#2 obtained by the method 200 of the embodiment of the present application.

[0225] The AST#2 may be parsed by the precompiler 300 in the embodiment of the present application.

[0226] It should be understood that the above is only an example, and AST#4 can also be obtained by other means, which is not limited in the embodiments of the present application.

[0227] 520, identifying tree nodes involved in risky operations in AST #4.

[0228] Tree nodes involving risky operations can be referred to as risky nodes. Risky nodes correspond to risky operations in the source contract. Risky operations are operations related to vulnerabilities.

[0229] It should be noted that the risk nodes in Strategy #1, Strategy #2, and Strategy #3 described below can be identified together or separately.

[0230] For example, a risk operation library can be pre-configured, containing a variety of vulnerabilities and their code-level characteristics. Risk operations in the security operation library, the blacklist library, the graylist library, and those involving access rights are all risk operations related to the vulnerabilities in the risk operation library. In this case, risk nodes can be identified in AST#4 based on the vulnerability's code-level characteristics and all risk nodes can be marked, or all risk operations in the source contract can be marked. The marked risk nodes can then be processed based on different strategies.

[0231] For example, the risk operations and their characteristics at the code level can be stored in the security operation library, blacklist library, graylist library, etc. In step 520, the risk nodes in each strategy can be identified based on each library, and then the risk nodes can be processed based on the corresponding strategy.

[0232] The embodiments of the present application do not limit the specific method of identifying risk nodes.

[0233] 530 , perform at least one of the following processes on AST#4 to obtain AST#5 (an example of the second syntax tree).

[0234] In other words, in step 530, at least one of the following strategies is executed on the risk node to obtain AST#5.

[0235] Strategy #1: Replace.

[0236] Specifically, step 530 may include replacing risk node #1 (an example of a first risk node) in the risk node with safety node #1 (an example of a first safety node), where risk node #1 involves risk operation #1 (an example of a first risk operation), and the safety node involves safety operation #1 (an example of a first safety operation). Safety operation #1 is used to replace risk operation #1.

[0237] Risky node #1 is the node corresponding to risky operation #1. Safe node #1 is the node corresponding to safe operation #1.

[0238] Replacing risky node #1 with safe node #1 is equivalent to replacing risky operation #1 in the source code with safe operation #1.

[0239] In Strategy #1, corresponding security operations can be pre-set for some risk operations. The security operations used to replace risk operations can achieve the same functions as the risk operations. In other words, these risk operations have replaceable security operations. Risk Node #1 can be any node with replaceable security operations. The number of risk nodes #1 can be one or more. The number of security nodes #1 can be one or more. This embodiment of the present application does not limit this.

[0240] In step 530, all nodes corresponding to risk operations with replaceable security operations in AST#4 can be replaced with nodes corresponding to security operations, so as to replace all risk operations with replaceable security operations in the source contract with corresponding security operations.

[0241] Optionally, according to a mapping relationship between multiple candidate risk operations and multiple candidate safety operations, risk node #1 is replaced with safety node #1, risk operation #1 belongs to the multiple candidate risk operations, and safety operation #1 belongs to the multiple candidate safety operations.

[0242] The mapping relationship between the multiple candidate risk operations and the multiple candidate security operations is used to indicate multiple candidate security operations that can replace the multiple candidate risk operations.

[0243] Exemplarily, the mapping relationship between the multiple candidate risk operations and the multiple candidate safety operations may be stored in a safety operation library.

[0244] The representation of the mapping relationship between the multiple risk operations and the multiple security operations can be set as needed. The embodiment of the present application does not limit the specific representation.

[0245] For example, the security operation library may store the multiple candidate risk operations and their corresponding security operations (ie, multiple candidate security operations).

[0246] For another example, the security operation library can store vulnerabilities related to multiple candidate risk operations and their corresponding security operations. Vulnerabilities related to candidate risk operations refer to vulnerabilities caused by candidate risk operations. That is, the mapping relationship between multiple candidate risk operations and multiple candidate security operations can be expressed as a mapping relationship between vulnerabilities related to the multiple candidate risk operations and multiple candidate security operations. A vulnerability is identified through AST#4, and the security operation corresponding to the vulnerability is determined based on the mapping relationship between the vulnerabilities related to the multiple candidate risk operations and the multiple candidate security operations, and then the tree node corresponding to the security operation is used to replace the tree node corresponding to the risk operation that caused the vulnerability.

[0247] Table 4 shows several vulnerabilities and their corresponding security operations.

[0248] Table 4

[0249] A true random number generator class may also be called a true random class.

[0250] It should be understood that Table 4 is merely an example and does not limit the embodiments of this application. For example, there may be multiple risk operations related to the set iteration order vulnerability, some of which can be replaced by the security operations in Table 4, while others may not be able to be replaced by the security operations in Table 4. For risk operations that cannot be replaced, please refer to Table 5 and will not be described in detail here.

[0251] If a risky operation in the source contract has a replaceable safe operation in the safe operation library, the risky operation can be replaced with the corresponding safe operation. In step 530, the risky operation can be replaced with the corresponding safe operation by replacing the risk node in the AST with the corresponding safe node. This helps reduce vulnerabilities in the contract and thus improves the security of the contract.

[0252] Strategy #2: Report an error.

[0253] Specifically, step 530 may include: throwing abnormal indication information.

[0254] The abnormal indication information can be used to indicate the existence of loopholes or risky operations in the source contract. That is, an error can be reported in step 530 to remind the user to handle it.

[0255] Optionally, the method 500 is applied to a compiler, and the method 500 may further include: refusing to pass the compilation of the source contract.

[0256] For example, the vulnerability prevention module is deployed in the compiler, and the compiler can throw an exception indication message and refuse to complete the compilation of the source contract.

[0257] The method 500 may also be applied to other modules besides a compiler.

[0258] Optionally, the method 500 is applied to the precompiler 300, and the method 500 may further include: refusing to pass the precompilation of the source contract.

[0259] For example, the vulnerability prevention module is deployed in the precompiler 300. The precompiler 300 can throw an exception indication message and refuse to complete the precompilation of the source contract. The precompiler 300 can be located within the compiler or as an independent functional module outside the compiler.

[0260] Optionally, step 530 may include: in a case where the risk node includes risk node #2 (an example of the third risk node), throwing abnormal indication information.

[0261] The risk operation corresponding to risk node #2 belongs to the risk set.

[0262] Exemplarily, the abnormality indication information may indicate relevant information about the risk operation involved in risk node #2. For example, the relevant information about the risk operation involved in risk node #2 may include at least one of the following: the risk operation involved in risk node #2 itself, the location of the risk operation involved in risk node #2 in the source contract, or the type of vulnerability caused by the risk operation involved in risk node #2.

[0263] The above is only an example, and the embodiments of the present application do not limit the representation form of the abnormal indication information.

[0264] The risk operation corresponding to risk node #2 can be any operation in the risk set. The number of risk nodes #2 can be one or more. This embodiment of the application does not limit this.

[0265] In strategy #2, if the risk operations involved in some or all risk nodes belong to the risk set, an exception indication message may be thrown.

[0266] There are some operations in the contract that will cause inconsistent results when running the same contract multiple times, that is, uncertainty loopholes appear in the contract, which will cause the blockchain nodes to be unable to reach a consensus.

[0267] The elements in the risk set can be risk operations related to uncertain vulnerabilities. In other words, the set of risk operations related to uncertain vulnerabilities can be used as the risk set.

[0268] Uncertainty vulnerabilities usually do not have safe operations that can be used to replace them, and can only be resolved by avoiding the use of risky operations related to uncertainties. In the solution of the embodiment of the present application, when a risky operation related to an uncertain vulnerability is identified, that is, when an uncertain vulnerability is identified, an error can be reported to remind the user to take action.

[0269] Furthermore, in the embodiments of the present application, if an uncertainty vulnerability is identified, the compilation or pre-compilation of the source contract can be refused. This prevents the contract from being deployed and executed, thus preventing uncertainty vulnerabilities from occurring at the source and improving the security of the contract.

[0270] Furthermore, a mechanism for enabling or disabling the uncertainty vulnerability prevention function can be provided to users. The uncertainty vulnerability prevention function is provided by policy #2, and enabling or disabling the uncertainty vulnerability prevention function is equivalent to enabling or disabling policy #2.

[0271] Users can choose to enable or disable the uncertainty vulnerability prevention feature.

[0272] In a possible implementation, a selection control may be displayed on a human-machine interface, where the selection control is used to enable or disable a function for preventing uncertain vulnerabilities.

[0273] For example, a user's operation on a selection control is obtained to change the state of the uncertainty vulnerability prevention feature. The state of the uncertainty vulnerability prevention feature can be enabled or disabled. For example, the user's operation on the selection space may be a click operation. After obtaining the user's click operation on the selection control, if the uncertainty vulnerability prevention feature is currently disabled, the uncertainty vulnerability prevention feature is enabled, that is, strategy #2 is executed. After obtaining the user's click operation on the selection control, if the uncertainty vulnerability prevention feature is currently enabled, the uncertainty vulnerability prevention feature is disabled.

[0274] It should be understood that the above is only an example and does not limit the solution of the embodiment of the present application. The specific method of enabling or disabling the prevention function of uncertainty vulnerability through the control can also be adopted in other ways, and the embodiment of the present application does not limit this.

[0275] In another possible implementation, a mechanism for enabling or disabling a function to prevent uncertain vulnerabilities may be provided for each operation.

[0276] In other words, whether or not Policy #2 is enforced for each operation is independent of each other, allowing users to locally enable or disable the uncertainty vulnerability prevention feature for each operation. For example, if a user disables uncertainty vulnerability prevention for a particular operation (i.e., partially disables Policy #2), no reminder message will be displayed for that operation. Policy #2 will still be enforced for other operations that have uncertainty vulnerability prevention enabled.

[0277] For example, an uncertainty annotation can be provided to disable the uncertainty vulnerability prevention function for the operation with the uncertainty annotation, that is, to disable Policy #2. The default state of Policy #2 can be set to be enabled. Users can add the uncertainty annotation to the operation that needs to disable Policy #2 to partially disable Policy #2.

[0278] Disabling Strategy #2 for an operation means not throwing an exception indication for that operation. For example, if an operation has an uncertainty annotation, Strategy #2 is disabled for that operation, and no error is triggered even if the operation belongs to the risk set.

[0279] For example, uncertainty annotation can be used to annotate a @NotDet rule.

[0280] Optionally, the risk operation corresponding to risk node #2 belongs to the risk set, and the risk operation corresponding to risk node #2 does not have an uncertainty annotation.

[0281] Alternatively, step 530 may include: the risk operation corresponding to risk node #2 belongs to the risk set. If the risk operation corresponding to risk node #2 has an uncertainty annotation, strategy #2 is closed for the risk operation, and risk node #2 will not trigger an error, that is, no exception indication information is thrown based on risk node #2.

[0282] In the embodiments of the present application, a mechanism for enabling or disabling the uncertainty vulnerability prevention function is provided to the user, allowing the user to disable the vulnerability prevention function, thereby preventing the vulnerability prevention function from negatively impacting language expression ability in certain scenarios. After disabling the uncertainty vulnerability prevention function, language expression ability can be improved in some situations.

[0283] The following is an illustrative description of the implementation of Strategy #2 using three examples (Example #1, Example #2, and Example #3).

[0284] Example #1:

[0285] In a possible implementation, the risk set may include all risk operations that may lead to uncertainty vulnerabilities.

[0286] That is, the risk operations related to uncertainty vulnerabilities in the risk set may include risk operations that may cause uncertainty vulnerabilities in some scenarios, and risk operations that may cause uncertainty vulnerabilities in any scenario.

[0287] In other words, if a risk operation causes uncertainty under all circumstances, then it is a risk operation that causes uncertainty vulnerabilities in all scenarios. If a risk operation causes uncertainty only under certain conditions but not under other conditions, then it is a risk operation that causes uncertainty vulnerabilities in some scenarios.

[0288] The uncertainty conditions corresponding to risky operations can be used to determine whether the risky operation will lead to uncertainty vulnerabilities. For example, if a risky operation meets the uncertainty conditions corresponding to the risky operation, then the risky operation will lead to uncertainty vulnerabilities. Otherwise, it will not lead to uncertainty vulnerabilities, as shown in Table 5. The operations in the graylist library are risky operations that may lead to uncertainty vulnerabilities in certain scenarios.

[0289] In this case, Risk Node #2 belongs to the Risk Set. This means that Risk Node #2 can be a node corresponding to a risk operation that will cause uncertainty in any situation, or a node corresponding to a risk operation that will cause uncertainty only under certain conditions. If Risk Node #2 exists among the Risk Nodes, it means that the source contract contains a risk operation that will cause an uncertainty vulnerability in any situation, or a risk operation that will cause an uncertainty vulnerability under certain conditions. The Vulnerability Prevention Module will report an error.

[0290] Furthermore, the compilation or precompilation of the source contract can also be rejected.

[0291] For example, when the risk operation corresponding to risk node #2 belongs to the risk set, an exception indication message is thrown and the compilation or pre-compilation of the source contract is rejected.

[0292] In other words, as long as the risk operation corresponding to risk node #2 may lead to uncertainty, an error will be reported and the compilation or pre-compilation of the source contract will be rejected.

[0293] Example #2:

[0294] In another possible implementation, the risk set may include risk operations that may lead to uncertain vulnerabilities in any scenario. That is, the operations related to uncertain vulnerabilities in the risk set may include risk operations that may lead to uncertain vulnerabilities in any scenario.

[0295] In this case, Risk Node #2 belongs to the Risk Set, meaning it corresponds to a risky operation that could lead to uncertainty in any case. If Risk Node #2 exists in the Risk Set, it means that the source contract contains a risky operation that could lead to an uncertainty vulnerability in any case, and the Vulnerability Prevention Module will report an error.

[0296] Furthermore, the compilation or precompilation of the source contract can also be rejected.

[0297] For example, when the risk operation corresponding to risk node #2 belongs to the risk set, an exception indication message is thrown and the compilation or pre-compilation of the source contract is rejected.

[0298] In other words, the risk operation corresponding to risk node #2 will inevitably lead to uncertainty, an error will be reported, and the compilation or pre-compilation of the source contract will be rejected.

[0299] Example #3:

[0300] In another possible implementation, a first risk set and a second risk set may be set. The first risk set and the second risk set may be regarded as two subsets of the risk set.

[0301] Elements in the first risk set will lead to uncertainty vulnerabilities in any scenario. Elements in the second risk set will lead to uncertainty vulnerabilities in some scenarios.

[0302] The first risk set may be set as a blacklist library, and the second risk set may be set as a graylist library.

[0303] Table 5 shows examples of the blacklist library and the greylist library.

[0304] Table 5

[0305] Optionally, when the risk operation corresponding to risk node #2 belongs to the blacklist library, an exception indication information is thrown.

[0306] For example, risk node #2 involves risk operation #2 (an example of the second risk operation). If risk operation #2 belongs to the blacklist library, an exception indication information is thrown.

[0307] Furthermore, when the risk operation corresponding to risk node #2 belongs to the blacklist library and risk node #2 does not have an uncertainty annotation, an exception indication information is thrown.

[0308] Otherwise, the exception indication information is not thrown based on the risk node #2. In other words, the throwing of the exception indication information is not triggered by the risk node #2.

[0309] In other words, if a risk node has an uncertainty annotation, no error processing will be performed on it. If the risk operation corresponding to a risk node belongs to the blacklist library and the risk node does not have an uncertainty annotation, the error reporting mechanism will be triggered and an exception indication information will be thrown.

[0310] The execution order of the above conditions can be set as needed. For example, first determine whether the risk operation corresponding to risk node #2 is on the blacklist. If so, then determine whether risk node #2 has an uncertainty annotation. For another example, first determine whether risk node #2 has an uncertainty annotation. If not, then determine whether the risk operation corresponding to risk node #2 is on the blacklist.

[0311] The above is only an example and does not limit the solutions of the embodiments of the present application.

[0312] Optionally, when the risk operation corresponding to risk node #2 belongs to the gray list library and the risk operation corresponding to risk node #2 meets the uncertainty condition corresponding to the risk operation, an exception indication information is thrown.

[0313] For example, if risk node #2 involves risk operation #2 (an example of the second risk operation), and if risk operation #2 is in the graylist and meets the uncertainty condition corresponding to risk operation #2, an exception indication message is thrown. The uncertainty condition corresponding to risk operation #2 is used to determine whether risk operation #2 will lead to uncertainty vulnerability.

[0314] When the risk operation corresponding to a risk node is included in the graylist, it can be determined whether the risk operation corresponding to the risk node meets the corresponding uncertainty condition. If so, the risk operation corresponding to the risk node will cause uncertainty, in which case an exception indication message can be thrown. Otherwise, the risk operation corresponding to the risk node will not cause uncertainty, in which case no exception indication message is needed.

[0315] In this way, the accuracy of the uncertainty vulnerability judgment results can be further improved, which is convenient for users to handle later and helps improve user experience.

[0316] Furthermore, when the risk operation corresponding to risk node #2 belongs to the gray list library, risk node #2 does not have an uncertainty annotation, and the risk operation corresponding to risk node #2 meets the uncertainty condition corresponding to the risk operation, an exception indication information is thrown.

[0317] Otherwise, no reminder information is output based on risk node #2. In other words, the exception indication information is not triggered by risk node #2.

[0318] In other words, if the risk operation corresponding to a risk node belongs to the gray list library, the risk node does not have an uncertainty annotation, and the risk operation corresponding to the risk node meets the corresponding uncertainty condition, the error reporting mechanism will be triggered and an exception indication message will be thrown. Otherwise, the error reporting mechanism will not be triggered.

[0319] The execution order of the above-mentioned conditions can be set as needed. For example, first determine whether the risk operation corresponding to risk node #2 belongs to the gray list library. If the risk operation corresponding to risk node #2 does belong to the gray list library, then determine whether the risk operation corresponding to risk node #2 meets the uncertainty condition. If it does, then determine whether risk node #2 has an uncertainty annotation. For another example, first determine whether risk node #2 has an uncertainty annotation. If risk node #2 does not have an uncertainty annotation, then determine whether the risk operation corresponding to risk node #2 belongs to the gray list library. If the risk operation corresponding to risk node #2 does belong to the gray list library, then determine whether the risk operation corresponding to risk node #2 meets the uncertainty condition.

[0320] The above is only an example and does not limit the solutions of the embodiments of the present application.

[0321] Furthermore, the compilation or precompilation of the source contract can also be rejected.

[0322] Exemplarily, throwing an exception indication message and rejecting the compilation or pre-compilation of the source contract may be bound together, that is, when the exception indication message is thrown, the compilation or pre-compilation of the source contract is rejected.

[0323] Exemplarily, throwing exception indication information and refusing compilation or precompilation of the source contract may be independent.

[0324] For example, if the risk operation corresponding to risk node #2 belongs to the blacklist library, an exception indication message is thrown and the compilation or pre-compilation of the source contract is rejected. If the risk operation corresponding to risk node #2 belongs to the graylist library, an exception indication message is thrown and the compilation or pre-compilation of the source contract is continued.

[0325] In other words, if a risky node inevitably leads to an uncertainty vulnerability, an exception indication message will be thrown and the compilation or pre-compilation of the source contract will be rejected. If a risky node only leads to an uncertainty vulnerability in some scenarios, an exception indication message will be thrown, but the compilation or pre-compilation of the source contract will continue.

[0326] For another example, if the risk operation corresponding to risk node #2 belongs to the blacklist library and risk node #2 does not have an uncertainty annotation, an exception indication message is thrown and the compilation or pre-compilation of the source contract is rejected. If the risk operation corresponding to risk node #2 belongs to the blacklist library and risk node #2 has an uncertainty annotation, an exception indication message is thrown, but the compilation or pre-compilation of the source contract continues.

[0327] In this case, the uncertainty annotation function is adjusted to prohibit the rejection of compilation or precompilation. In other words, if the risky node will inevitably lead to an uncertainty vulnerability and does not have an uncertainty annotation, an exception indication will be thrown and the compilation or precompilation of the source contract will be rejected. If the risky node will inevitably lead to an uncertainty vulnerability, but the user has set an uncertainty annotation for it, an exception indication will be thrown, but the compilation or precompilation of the source contract will continue.

[0328] Strategy #3: Add permission detection conditions;

[0329] Add a permission detection condition to risk node #3 (an example of the second risk node) in the risk node. The permission detection condition is used to determine the identity of the caller when the function indicated by risk node #3 is called.

[0330] Risk node #3 involves access rights.

[0331] Adding a check node (i.e., permission check condition) to the AST is equivalent to adding a check statement to the contract code. For example, adding a check statement for the function caller at the beginning of the function body.

[0332] When the target contract is subsequently run, it will determine whether the permission check conditions are met, that is, verify the identity of the function caller. If so, identity authentication is successful, and the relevant operations corresponding to risk node #3 are allowed to execute. If not, it means that identity authentication failed and an error is reported. Furthermore, if identity authentication fails, the contract execution can be terminated.

[0333] The error reporting in strategy #3 occurs at the runtime stage, and strategy #3 can also be called a runtime error reporting mechanism.

[0334] The main reason for permission control vulnerabilities in smart contracts is the failure to clearly define or carefully check the access permissions of functions in the contract, allowing malicious attackers to call functions that they should not be able to access.

[0335] In an embodiment of the present application, additional permission detection conditions are added to the tree nodes involving access rights, so that the contract needs to determine whether the identity of the caller is legal during operation, which is conducive to improving the security of contract operation and avoiding permission control loopholes.

[0336] For example, in step 530, the tree nodes of AST#4 can be traversed, and strategies #1, #2, and #3 can be executed to obtain AST#5. AST#5 can be considered as an AST with vulnerability prevention mechanisms added. If only strategy #2 is executed, AST#5 and AST#4 can have the same syntax tree structure.

[0337] AST#5 can be used to generate a target contract. For example, AST#5 can be converted into code to obtain the target contract.

[0338] This helps avoid vulnerabilities in the target contract's code.

[0339] Method 500 and method 200 may be used in combination.

[0340] Exemplarily, method 500 may be executed between steps 240 and 250. Specifically, AST#2 generated in step 240 is used as AST#4 in method 500, and AST#4 is processed by method 500 to obtain AST#5. AST#5 is used to replace AST#2 in step 250, that is, in step 250, the target contract is generated based on AST#5.

[0341] In the solution of the embodiment of the present application, corresponding preventive measures are set for a variety of common vulnerabilities in the field of smart contracts, greatly improving the security of smart contracts. At the same time, these measures can reduce the processing required by users at the code level, which is conducive to simplifying the coding process, reducing usage costs, and improving development efficiency. Moreover, this can also lower the learning threshold for contract development, thereby improving the ease of use of the language. For example, this solution can be applied to the compilation or pre-compilation process of JSmarter, reducing the processing required by users at the code level, which can further lower the learning threshold for contract development, that is, reduce the entry cost.

[0342] Exemplarily, replacing some risky operations with safe operations can help avoid some vulnerabilities. For example, using safe operations to replace risky operations related to reentrancy vulnerabilities, integer overflow vulnerabilities, pseudo-random vulnerabilities, and set iteration order vulnerabilities can reduce or avoid these vulnerabilities. Exemplarily, for some risky operations, exception indication information is thrown to prompt the user to handle it. For example, for risky operations related to uncertain vulnerabilities, an error can be reported to prompt the user to handle it, thereby reducing uncertain vulnerabilities. Exemplarily, for some operations involving permissions, permission detection conditions are added to them so that the visitor's identity is verified at runtime, which helps avoid permission control vulnerabilities.

[0343] Smart contract vulnerabilities mostly originate at the language level. The present embodiment optimizes the processing of smart contract programming languages. In the solution of the present embodiment, vulnerability prevention measures can be embedded within the language itself, for example, within the compiler or precompiler. This helps prevent vulnerabilities from arising at the source, thereby improving the security of the programming language, or in other words, improving the security of smart contracts.

[0344] Smart contracts face a variety of migration requirements, such as migrating from public to private environments, and from permissionless to permissioned chains. However, the underlying architectures and supported smart contract programming languages ​​of various contract runtime environments (e.g., blockchain platforms) vary significantly, making it difficult to effectively migrate smart contracts between them. This results in low smart contract portability. This requires reimplementing related smart contracts during application migration, resulting in high migration costs. Smart contract portability refers to the ability of a written smart contract to run in multiple runtime environments.

[0345] Therefore, how to improve the portability of smart contracts has become an urgent problem to be solved.

[0346] In view of this, an embodiment of the present application provides a method for processing smart contracts, which is conducive to improving the migration efficiency of smart contracts.

[0347] Figure 6 illustrates another method for processing smart contracts provided by an embodiment of the present application. Method 600 may also be referred to as a method for migrating smart contracts, or a method for converting programming languages. In method 600, platform migration is achieved through concept mapping.

[0348] The method 600 may be executed by a platform migration device.

[0349] The platform migration device can also be deployed in other devices as a functional module of the other devices. In this case, the platform migration device can also be called a platform migration module.

[0350] Exemplarily, the platform migration module may be deployed in a compiler.

[0351] Exemplarily, the platform migration module can be deployed in the precompiler 300 of the embodiment of the present application. For example, the precompiler 300 can include a syntax parsing module 310 and a platform migration module. The platform migration module can act on the code generation stage. In this case, the platform migration module and the code generation module 330 can be integrated into the same module.

[0352] As shown in FIG6 , method 600 may include the following steps.

[0353] 610. Obtain AST#6 (an example of the fourth syntax tree) corresponding to the source contract.

[0354] As a possible implementation method, AST#6 corresponding to the source contract can be the AST of the source contract.

[0355] For example, AST#6 can be parsed by a compiler. For example, if the source contract is written in Java, the compiler can be a Java compiler. For another example, if the source contract is written in Solidity, the compiler can be a Solidity compiler.

[0356] As another possible implementation, AST#6 can be obtained by processing the AST of the source contract.

[0357] Exemplarily, the AST#6 may be the AST#2 obtained by the method 200 of the embodiment of the present application, or may be the AST#5 obtained by the method 500 of the embodiment of the present application.

[0358] For example, AST#6 may be parsed by the precompiler 300 in the embodiment of the present application.

[0359] It should be understood that the above is only an example, and AST#6 can also be obtained by other means, which is not limited in the embodiments of the present application.

[0360] 620. Replace the initial tree node #S1 (an example of the second initial node) in AST #6 with the target tree node #T1 (an example of the second target initial node). Initial tree node #S1 corresponds to initial syntax element #1 (an example of the first initial syntax element) in the source language, and target tree node #T1 corresponds to target syntax element #1 (an example of the first target syntax element) in the target language. The source language is the programming language of the source contract, and the target language is the programming language of the target contract. The target contract is determined based on the source contract.

[0361] The initial tree node #S1 can be any node in AST#6.

[0362] The number of initial tree nodes #S1 can be one or more, which is not limited in the embodiment of the present application.

[0363] In step 620, the mapping of grammatical elements in the source language and the target language is implemented. That is, the grammatical elements in the source language are mapped to the grammatical elements in the target language. The mapping of grammatical elements can also be understood as the mapping of grammatical concepts.

[0364] Optionally, step 620 may include: replacing the initial tree node #S1 with the target tree node #T1 according to the mapping relationship between multiple candidate initial syntax elements and multiple candidate target syntax elements, the initial syntax element #1 belongs to multiple candidate initial syntax elements, and the target syntax element #1 belongs to multiple candidate target syntax elements.

[0365] The plurality of candidate initial grammatical elements are grammatical elements in a source language, and the candidate target grammatical elements are grammatical elements in a target language.

[0366] The mapping relationship between multiple candidate initial grammatical elements and multiple candidate target grammatical elements is the mapping relationship between grammatical concepts in the source language and the target language.

[0367] The mapping relationship between the multiple candidate initial grammatical elements and the multiple candidate target grammatical elements can be stored in a concept mapping table. The mapping relationship between the multiple candidate initial grammatical elements and the multiple candidate target grammatical elements is a mapping relationship at the language level. Accordingly, the concept mapping in step 620 is a mapping at the language level.

[0368] In step 620, the nodes corresponding to the syntax elements of the source language in AST#6 can be mapped to the nodes corresponding to the syntax elements in the target language according to the above mapping relationship, so as to realize the mapping of the syntax elements of the source language in the source contract to the syntax elements of the target language.

[0369] Table 6 shows the mapping relationship between the syntax elements of JSmarter and Solidity. JSmarter can be the source language and Solidity can be the target language.

[0370] Table 6

[0371] For example, as shown in Table 6, the mapping mode of the syntax element may include at least one of the following: direct mapping, extended replacement, or supplementary mapping.

[0372] For grammatical concepts contained in both the source language and the target language, they are represented as direct mapping relationships in the mapping relationship.

[0373] Grammatical concepts contained in both the source language and the target language can be understood as grammatical elements that have the same grammatical function and the same grammatical structure in the source language and the target language.

[0374] For example, as shown in Table 6, "transfer" in JSmarter and "transfer" in Solidity are grammatical elements with the same grammatical function and grammatical structure. "transfer" is a grammatical concept contained in both JSmarter and Solidity. In step 620, the node corresponding to transfer in AST#6 can be directly converted to the node corresponding to "transfer" in Solidity according to the mapping relationship in Table 6.

[0375] For grammatical concepts that exist in the source language but do not exist in the target language, the mapping relationship is represented as an expansion-replacement relationship.

[0376] For example, for a grammatical concept #A in the source language, if there is no predefined grammatical element in the target language that can realize the grammatical function of the grammatical concept #A, the grammatical concept #A does not exist in the target language.

[0377] In this case, the syntax element #A in the source language corresponds to a code segment that implements the syntax element #A in the target language, or in other words, a code segment that is implemented based on the syntax element in the target language. If the initial syntax element #1 is the syntax element #A, the target syntax element #1 may include the code segment.

[0378] For example, in JSmarter, "json2Obj()" is used to convert a JSON string into an object. Solidity doesn't have a predefined function that implements this syntax. As shown in Table 6, "json2Obj()" corresponds to a code segment that implements the "json2Obj()" syntax in Solidity. Initial syntax element #1 can be json2Obj(), initial tree node #S1 can be the node corresponding to json2Obj(), and target tree node #T1 corresponds to the corresponding code segment in Table 6, i.e., target syntax element #1.

[0379] For grammatical concepts that exist in the target language but do not exist in the source language, they are represented as supplementary mapping relationships in the mapping relationship.

[0380] For example, for grammatical elements with the same grammatical function but different grammatical structures in the source and target languages, the grammatical concept used by the grammatical element in the target language may not exist in the grammatical element in the source language. In this case, a supplementary mapping approach can be used for mapping. Target grammatical element #1 and initial grammatical element #1 implement the same grammatical function, but the grammatical concept used by target grammatical element #1 does not exist in initial grammatical element #1. In this case, mapping initial tree node #S1 to target tree node #T1 can be accomplished by supplementing initial tree node #S1 with a node corresponding to the grammatical concept used by target grammatical element #1 in the target language.

[0381] For example, as shown in Table 6, for the syntax element of structure variable (an example of initial syntax element #1), the keyword storage is not included in the structure variable declaration in JSmarter. When converted to Solidity, the concept of storage needs to be supplemented, that is, a node corresponding to storage is added to the initial tree node #S1 to realize the mapping of tree node #S1 to tree node #T1.

[0382] Identity information and permission controls may differ between different platforms. For example, within a consortium blockchain, accounts are divided into different organizations, each belonging to a different organization. These organizations have different permissions. Public blockchains only have the concept of accounts, not organizations. If the source contract is intended for a consortium blockchain, porting it to a public blockchain requires addressing the differences in identity information and permission controls between the two platforms. These differences can be addressed through platform-level mapping. Specifically, this can be achieved through steps 630 and / or 640.

[0383] 630, replace the initial tree node #S2 (an example of the first initial node) in AST #6 with the target tree node #T2 (an example of the first target node). The initial operation #1 (an example of the first initial operation) involved in the initial tree node #S2 is related to the identity information in platform #2 (an example of the first platform), and the replacement operation #1 (an example of the first replacement operation) involved in the target tree node #T2 is related to the identity information in platform #3 (an example of the second platform). Platform #3 can be used to deploy the target contract. That is, platform #3 supports the deployment of the target contract. The target contract is determined based on the source contract.

[0384] For example, Platform #2 can be a blockchain platform that supports the source language. Alternatively, if the source language is an internal DSL, Platform #2 can be a platform that supports the host language of the source language. Platform #3 can be a platform that supports the target language.

[0385] Platform #2 can also be called Blockchain Platform #2. Platform #3 can also be called Blockchain Platform #3. Platform #2 and Platform #3 are different platforms.

[0386] For example, taking the JSmarter language of the embodiment of the present application as the source language, platform #2 can be a platform that supports the Java language. Platform #3 can be a platform that does not support the Java language. For example, platform #2 can be platform #1 mentioned above.

[0387] Optionally, step 630 includes: replacing the initial tree node #S2 with the target tree node #T2 according to a mapping relationship between multiple candidate initial operations and multiple candidate replacement operations, the initial operation #1 belongs to the multiple candidate initial operations, and the replacement operation #1 belongs to the multiple candidate replacement operations.

[0388] For example, consider Platform #2, a consortium chain platform, and Platform #3, a public chain platform. The public chain platform lacks organization information, and when migrating from the consortium chain platform to the public chain platform, operations related to organizations must be removed. In the mapping relationship between multiple candidate initial operations and multiple candidate replacement operations, the multiple candidate initial operations can include operations on organizations, and the multiple candidate replacement operations can include operations on the public ledger. This mapping relationship between the multiple candidate initial operations and the multiple candidate replacement operations can be used to indicate the mapping relationship between operations on organizations and operations on the public ledger.

[0389] For example, platform #2 may involve operations on channels, which are operations on organizations. These operations can correspond to operations on public ledgers. In other words, the operations on the channels fall under multiple candidate initial operations, while the operations on the public ledger fall under these multiple candidate replacement operations. In the mapping relationship between the multiple candidate initial operations and the multiple candidate replacement operations, the operations on the channels correspond to operations on the public ledger.

[0390] Exemplarily, the mapping relationship between the multiple candidate initial operations and the multiple candidate replacement operations may be stored in a concept mapping table. The mapping relationship between the multiple candidate initial operations and the multiple candidate replacement operations belongs to a mapping relationship at the platform level.

[0391] Step 630 can be used to process the differences in identity information between different platforms.

[0392] 640, embed the permission control code into the target contract. The permission control code is used to describe the permission relationship corresponding to the identity information in platform #2.

[0393] The permission control code can be sample code containing permission control logic. This permission control code can also be referred to as the permission control sample code. The permission control sample code can be pre-built based on the permission relationships between the various identity information in Platform #2. For example, if Platform #2 is a consortium chain platform, sample code containing permission control logic and instructions for use can be pre-built based on the permission relationships between various organizations.

[0394] Users can modify and call permission control codes as needed to implement permission control in smart contracts, which helps reduce migration costs.

[0395] Optionally, permission control code can be embedded in the target contract in the form of comments.

[0396] For example, when mapping, the permission control code and its usage instructions can be embedded in the header of the target contract in the form of comments.

[0397] Users only need to remove comments and modify and call as needed to obtain the required smart contract, achieving permission control at a lower development cost.

[0398] Step 640 can be used to handle the differences in permission control between different platforms.

[0399] Step 630 and step 640 can be regarded as platform-level mapping.

[0400] 650, filling AST#7 into the target structure, which is defined by the target contract template, to generate the target contract.

[0401] AST#7 can be any one of the following: the AST obtained after processing in step 620, the AST obtained after processing in step 630, or the AST obtained after processing in steps 620 and 630.

[0402] The target contract template may specify structural features of grammatical concepts for filling in after concept mapping to generate the target contract.

[0403] The target contract module can be defined by a language-level mapping relationship.

[0404] FIG7 shows a schematic diagram of the structure of a target contract template using the Solidity language.

[0405] Exemplarily, the target contract template may include at least one of the following structures: interface declaration, contract declaration, structure declaration, property declaration, event declaration, trigger event, error declaration, function declaration, variable declaration, constant declaration, built-in variable reading, (built-in) function call, conditional statement, loop statement, exception throwing, return statement and other basic syntax and processing logic.

[0406] Specifically, step 650 may include: performing feature extraction on AST#7 to obtain structural features of the tree nodes, and filling the structural features into the target structure to generate the target contract.

[0407] Exemplarily, the tree nodes in AST#7 are traversed to extract structural features. Taking a function call node as an example, the structural features may include the function name, the function caller, or the function parameter values. The structural features are then added to the target structure indicated by the target contract template to generate the target contract.

[0408] In an embodiment of the present application, a smart contract language conversion interface is provided, which can convert a smart contract written in a source language into a smart contract in another programming language, which is conducive to improving the portability of the programming language, or in other words, improving the portability of the smart contract and reducing the migration cost.

[0409] Specifically, in an embodiment of the present application, the grammatical elements of the source language are converted into grammatical elements between the target language to achieve the conversion from the smart contract in the source language to the smart contract in the target language.

[0410] In addition, in an embodiment of the present application, operations related to the identity in platform #2 are converted into operations related to the identity in platform #3, thereby processing the differences in identity information between platform #2 and platform #3, thereby facilitating the migration of smart contracts between different operating environments.

[0411] Furthermore, in this embodiment, permission control codes are injected into the target contract. These codes indicate the permission relationships within platform #2, allowing for handling differences in permission control between platform #2 and platform #3. This allows users to modify and call permission control codes as needed, thereby implementing permission control within the smart contract and reducing migration costs.

[0412] In the embodiments of the present application, method 200, method 500, and method 600 can be used in combination. For example, any two of method 200, method 500, and method 600 in the embodiments of the present application can be used in combination. For another example, in the embodiments of the present application, method 200, method 500, and method 600 can be used in combination.

[0413] When used in combination with other solutions, method 600 can be used as a specific implementation of the language conversion function. Furthermore, the language conversion function can be used as an optional function, that is, a mechanism for enabling or disabling the language conversion function is provided to the user.

[0414] The user can enable or disable the language conversion function as needed. If the user disables the language conversion function, method 600 is not executed. If the user enables the language conversion function, method 600 is executed.

[0415] When used in conjunction with other solutions, method 500 can be used as a specific implementation of the vulnerability prevention function. Furthermore, the vulnerability prevention function can be an optional function, that is, providing users with a mechanism to enable or disable the vulnerability prevention function.

[0416] The user can enable or disable the vulnerability prevention function as needed. If the user disables the vulnerability prevention function, method 500 is not executed. If the user enables the vulnerability prevention function, method 500 is executed.

[0417] The combination of method 200 and method 500 can be referred to above and will not be described in detail here.

[0418] As a possible implementation, method 200 and method 600 may be used in combination.

[0419] For example, the language conversion function can be an optional function of the precompiler. If the user turns off the language conversion function, only method 200 is executed, and method 600 is not executed, and a Java character stream can be output. If the user turns on the language conversion function, both method 200 and method 600 are executed, and a character stream in the target language is output.

[0420] When the method 200 and the method 600 are used in combination, the AST#2 in the method 200 can be used as the AST#6 in the method 600. Step 250 in the method 200 can be implemented by the method 600.

[0421] As another possible implementation, method 500 and method 600 may be used in combination.

[0422] For example, the language conversion function may be an optional function in the compiler.

[0423] For example, the vulnerability prevention function may be an optional function in the compiler.

[0424] When the method 500 and the method 600 are used in combination, the AST#5 in the method 500 can be used as the AST#6 in the method 600.

[0425] As another possible implementation, method 200 , method 500 , and method 600 may be used in combination.

[0426] Illustratively, the language conversion function may be an optional function of the precompiler.

[0427] Exemplarily, the vulnerability prevention function may be an optional function in the precompiler.

[0428] When methods 200, 500, and 600 are used in combination, AST#2 in method 200 can be used as AST#4 in method 500, that is, method 500 can be executed after step 240. AST#5 in method 500 can be used as AST#6 in method 600, and method 600 can be executed.

[0429] The following uses the combination of method 200, method 500, and method 600 as an example to illustrate the solution of the embodiment of the present application.

[0430] FIG8 shows a schematic diagram of the architecture of a JSmarter precompiler.

[0431] As shown in FIG8 , the precompiler of JSmarter may include a syntax parsing module 310 , a vulnerability prevention module 320 and a platform transplantation module 330 .

[0432] The syntax parsing module 310 can be used in the syntax parsing phase. The vulnerability prevention module 320 can be used in the semantic analysis phase. The platform transplantation module 330 can be used in the code generation phase. The platform transplantation module 330 and the code generation module 330 in FIG3 can be the same module.

[0433] The precompiler shown in Figure 8 can preprocess the extended syntax, which is conducive to ensuring that the extended syntax can pass compilation. At the same time, it introduces a vulnerability prevention mechanism and a language conversion mechanism to process the contract code, thereby improving the security and portability of the contract.

[0434] For example, as shown in Figure 8, the input of the syntax parsing module 310 can be the source contract developed using JSmarter, that is, the JSmarter source code, and the output can be the parsed AST (that is, AST#2). The vulnerability prevention module 320 can be used to detect risky operations and prevent security vulnerabilities. The input of the vulnerability prevention module 320 can be the AST (that is, AST#2) output by the syntax parsing module 310, and the output can be the AST (that is, AST#5) with the vulnerability defense mechanism added. The AST with the vulnerability defense mechanism added can be called the checked AST. The platform porting module 330 can be used to convert the code of the source contract into the code of the target contract in other languages. The input of the platform porting module 330 can be the AST output by the vulnerability prevention module 320, and the output can be the character stream of the target contract supported by the operating environment.

[0435] In the solution of the embodiment of the present application, the precompiler includes a syntax parsing module 310, a vulnerability prevention module 320 and a platform porting module 330. On the basis of ensuring that the extended syntax is compilable, vulnerabilities are prevented at the language level, thereby improving the security of the programming language, enabling porting to other platforms, and improving the portability of the programming language.

[0436] Figure 9 shows a schematic diagram of the workflow of the JSmarter precompiler. The solution shown in Figure 9 can be regarded as a specific implementation of the combination of method 200, method 500 and method 600, and does not limit the solution of the embodiment of the present application.

[0437] For example, as shown in Figure 9, the extended syntax in JSmarter can include keywords, data types, built-in variables, and built-in functions. Users can use the JSmarter language to write source contracts. The precompiler processes the source contract (i.e., the JSmarter source code in Figure 9) to obtain a character stream in the target language, i.e., the target contract. JSmarter's precompiler generally follows the principles of Java compilation and includes three stages: syntax parsing, semantic analysis, and code generation. The following is an exemplary description of each stage based on the three modules shown in Figure 8.

[0438] FIG10 is a schematic diagram showing the workflow of the syntax parsing module 310 .

[0439] As shown in FIG10 , the JSmarter source code (ie, the JS source code in the figure) is input into the syntax parsing module 310 , and the syntax parsing module 310 executes steps 910 to 930 to output the parsed AST.

[0440] 910, in the lexical analysis sub-phase, traverse the token sequence of the JSmarter source code and execute steps 911 and 912.

[0441] 911, token recognition.

[0442] Identify the token of the target keyword.

[0443] 912, annotation generation.

[0444] Convert the target keyword's token into the corresponding Java annotation.

[0445] 920, in the syntax analysis sub-phase, traverse the tree nodes of the AST (an example of AST#1) corresponding to the JSmarter source code and execute steps 921 and 922. The AST corresponding to the JSmarter source code is generated based on the token sequence processed in step 910.

[0446] 921, annotation processing.

[0447] If the detected tree node is modified with the Java annotation obtained in step 912, the corresponding node is added, deleted or modified, etc., so that the tree node complies with the contract declaration specification of platform #1.

[0448] 922, Syntax interface mapping.

[0449] If the detected tree node corresponds to an extended data type, built-in variable, or built-in function, it is mapped to a matching syntax interface defined in the precompiler. Taking platform #1 as an example, the syntax interface is implemented based on the HF platform's underlying call API. For example, the syntax interface defined in the precompiler and its corresponding extended syntax can be found in Table 3.

[0450] In addition, as shown in Table 3, if the detected tree node is decorated with a Java annotation, it can be mapped to a matching grammatical interface defined in the precompiler. As shown in Table 3, if the detected tree node corresponds to an extended keyword, and the extended keyword is a keyword other than the target keyword, it can also be mapped to a matching grammatical interface defined in the precompiler.

[0451] In the above operations, the precompiler can simultaneously add related import dependencies.

[0452] This way, the extended syntax can be converted to the corresponding API in platform #1.

[0453] 930. After traversing all tree nodes of the AST corresponding to the JSmarter source code, output the parsed AST (an example of AST#2).

[0454] FIG11 is a schematic diagram showing the workflow of the vulnerability prevention module 320 .

[0455] As shown in FIG11 , the AST output by the syntax analysis module 310 is input to the vulnerability prevention module 320 , and the vulnerability prevention module 320 executes steps 1010 and 1020 to output the checked AST.

[0456] 1010 , traverse the tree nodes in the AST output by the syntax parsing module 310 , and execute steps 1011 to 1014 for each tree node.

[0457] 1011. If the operation involved in the tree node exists in the safe operation library, a replacement prevention strategy is used, that is, the tree node is replaced with a tree node corresponding to the operation in the safe operation library.

[0458] For example, if the operations involved in a tree node may cause a reentrancy vulnerability, an integer overflow vulnerability, a pseudo-random vulnerability, or a set iteration order vulnerability, a replacement prevention strategy is used to replace the tree node with a tree node corresponding to the operation in the security operation library, so as to replace the operations involved in the tree node with the corresponding security operations in the security operation library.

[0459] The operation involved in the tree node exists in the security operation library, that is, the operation involved in the tree node has a replaceable security operation.

[0460] If the operation involved in the tree node exists in the blacklist library or the whitelist library, step 1012 or 1013 is executed.

[0461] Steps 1012 and 1013 can be used to handle various uncertainty vulnerabilities, such as random number generation, timestamp dependency, unchecked return values, program concurrency, customized memory usage, system command execution, external file access, or environment variable acquisition.

[0462] 1012. If the operation involved in the tree node exists in the blacklist library, determine whether the tree node has the @NotDet rule annotation. If the tree node has this annotation, it can be assumed that the user has approved and allowed the uncertainty here, and the precompiler will not process it. If the tree node does not have this annotation, the compilation error mechanism is triggered, that is, the contract code is rejected from compilation, and an exception indication message is thrown to prompt the user to address the vulnerability.

[0463] 1013. If the operation involved in the tree node exists in the graylist library, determine whether the operation involved in the tree node meets the corresponding uncertainty condition. If not, the operation involved in the tree node will not cause uncertainty, and the precompiler will not process it. If it does, determine whether the tree node has the @NotDet rule annotation. If the tree node has this annotation, it can be assumed that the user acknowledges and allows the uncertainty to be retained here, and the precompiler will not process it. If the tree node does not have this annotation, the compilation error mechanism is triggered, that is, the contract code is rejected from compilation, and an exception indication message is thrown to prompt the user to address the vulnerability.

[0464] Step 1014 may be used to address permission access control vulnerabilities.

[0465] 1014. If the tree node involves access permission control, add a verification node corresponding to the verification statement for the function caller before the node corresponding to the function body.

[0466] This involves adding a check for the function caller at the beginning of the function body. This check serves as a runtime condition to implement runtime detection. Specifically, the contract code performs additional verification of the function caller's identity during actual execution. If the authentication fails, the runtime error mechanism is triggered, terminating the contract execution and throwing an exception.

[0467] 1020. After traversing all tree nodes in the AST output by the syntax parsing module 310, an AST with vulnerability prevention mechanisms added is output (an example of AST#5).

[0468] After traversing all tree nodes, a vulnerability prevention mechanism is added to the corresponding tree nodes and the checked AST is output.

[0469] Figure 12 shows a schematic diagram of the workflow of the platform migration module 330. In the solution shown in Figure 12, a concept mapping strategy is designed to address the differences between the source language and the target language in blockchain platform mechanisms and contract syntax, and a concept mapping table is constructed for rapid language conversion.

[0470] As shown in Figure 12, the AST output by the vulnerability prevention module 320 is input into the platform transplantation module 330, and the platform transplantation module 330 executes steps 1110 to 1140 to output a character stream in the target language. For example, the platform transplantation function can be turned on or off by the user. If the user turns off the platform transplantation function, a character stream in the Java language is generated. If the user turns on the platform transplantation function, steps 1110 to 1140 are executed to generate a character stream in a language other than Java.

[0471] 1110, obtain a concept mapping table.

[0472] The concept mapping table can indicate the mapping relationship between the source language and the target language at the platform level and the language level. The language-level mapping relationship can be used to define the target contract template.

[0473] The mapping relationship at the language level refers to the mapping relationship between multiple candidate initial syntax elements and multiple candidate target syntax elements. The mapping relationship at the platform level refers to the mapping relationship between multiple candidate initial operations and multiple candidate replacement operations.

[0474] As shown in FIG9 , after obtaining the concept mapping table, concept mapping can be performed on the baseline grammar, and feature extraction can be performed on the AST processed by the concept mapping to generate the target contract.

[0475] The benchmark grammar may be a JSmarter grammar. The process of concept mapping may be implemented through steps 1120 and 1130 .

[0476] The process of performing feature extraction on the AST after the concept mapping process to generate the target contract can be implemented through step 1140.

[0477] 1120 , process the differences in identity information and authority control information between platform #2 and platform #3.

[0478] Specifically, step 1120 can be implemented through steps 1121 and 1122.

[0479] 1121. If platform #3 is a public chain, according to the concept mapping table, the organization-related operations are mapped to the corresponding public ledger operations. In other words, the concepts of the organization-related operations are mapped to the corresponding concepts of the public ledger operations.

[0480] 1122, embed permission control sample code and usage instructions in the form of comments in the target contract header.

[0481] Exemplarily, step 1122 may be performed after step 1140 , and after embedding the relevant content, the character stream of the target contract may be output.

[0482] 1130, perform concept mapping on core concepts.

[0483] The tree nodes in the AST output by the vulnerability prevention module 320 are traversed to identify the core concepts in JSmarter, and the core concepts in JSmarter are mapped to concepts in the target language according to the mapping relationship in the concept mapping table.

[0484] For example, the four core concepts of extended keywords, data types, built-in variables, and built-in functions shown in FIG12 are identified and mapped to core concepts in the target language.

[0485] It should be understood that Figure 12 is only an example and does not limit the core concepts in JSmarter to have corresponding concepts in the target language. The specific mapping method can be referred to above and will not be repeated here.

[0486] 1140 , fill the mapping result into the target structure to generate a target contract, where the target structure is defined by the target contract template.

[0487] The target contract template is in the target language.

[0488] The solution of the embodiment of the present application can complete the conversion between codes of different programming languages, and can also realize the conversion of identity information and permission control between different operating environments, solve the difference problem between different operating environments, and thus reduce the migration cost of the contract by more than 30%.

[0489] Figure 13 is a schematic block diagram of the operating environment of the smart contract in an embodiment of the present application.

[0490] As shown in Figure 13, the character stream of Jsmarter can be precompiled by the precompiler of the embodiment of the present application to obtain the character stream of the target contract. The character stream of the target contract can be a character stream of Java language or a character stream of a language other than Java language. The character stream of the target contract can be deployed as a chain code in the running environment. For example, the character stream of the target contract can be deployed as an internal chain code in the internal environment. Taking the HF platform as an example, the peer node can directly call the internal chain code. For another example, the character stream of the target contract can also be deployed as an external chain code in an external environment, for example, on Kubernetes. When the external chain code needs to be called, the peer node starts, configures, builds and calls the external chain code through the HF middleware.

[0491] For a detailed description of the operating environment, please refer to the previous article. To avoid repetition, the description will not be expanded here.

[0492] The apparatus of the embodiment of the present application is described below with reference to Figures 14 to 17. It should be understood that the apparatus described below can execute the method of the embodiment of the present application described above. To avoid unnecessary repetition, repeated descriptions are appropriately omitted when introducing the apparatus of the embodiment of the present application.

[0493] Figure 14 is a schematic block diagram of a smart contract processing device according to an embodiment of the present application. The processing device 2000 shown in Figure 14 can be used to execute the method shown in Figures 1, 2, 5, 6, or 9.

[0494] The processing device 2000 includes a first acquisition module 2010 and a first processing module 2020 .

[0495] In one possible implementation, the processing device 2000 may be used to execute the method shown in Figure 5. Furthermore, the processing device 2000 may also be used to execute the method shown in Figure 2 and / or Figure 6.

[0496] The first acquisition module 2010 is used to acquire a first syntax tree of the source contract.

[0497] The first processing module 2020 is configured to:

[0498] identifying a risk node in the first syntax tree, the risk node involving a risky operation;

[0499] Perform at least one of the following processes on the first syntax tree to obtain a second syntax tree:

[0500] Replace the first risk node in the risk node with the first security node, the first risk node involves a first risk operation, the first security node involves a first security operation, and the first security operation is used to replace the first risk operation; or, add a permission detection condition to the second risk node in the risk node, and the permission detection condition is used to determine the identity of the caller when the function indicated by the second risk node is called.

[0501] Optionally, the first processing module 2020 is further configured to: when the risk node includes a third risk node, throw abnormal indication information based on the third risk node.

[0502] Optionally, the processing device 2000 is applied to a compiler.

[0503] Optionally, the first processing module 2020 is further used to: when the risk node includes a third risk node, refuse to pass the compilation process of the source contract.

[0504] Optionally, the third risk node relates to a second risk operation, the second risk operation belongs to a first risk set, and the first risk set includes risk operations that may cause uncertainty vulnerabilities in any scenario.

[0505] Optionally, the third risk node involves a second risk operation, the second risk operation belongs to a second risk set, the second risk set includes risk operations that may cause uncertainty vulnerabilities in some scenarios, the second risk operation satisfies the uncertainty condition corresponding to the second risk operation, and the uncertainty condition corresponding to the second risk operation is used to determine whether the second risk operation causes uncertainty vulnerabilities.

[0506] Optionally, the third risk node does not have an uncertainty annotation, or the first processing module 2020 is used to: when the risk node includes the third risk node and the third risk node has an uncertainty annotation, not throw an exception indication information based on the third risk node.

[0507] Optionally, the first processing module 2020 is specifically used to: replace the first risk node with the first safety node according to the mapping relationship between multiple candidate risk operations and multiple candidate safety operations, the first risk operation belongs to multiple candidate risk operations, and the first safety operation belongs to multiple candidate safety operations.

[0508] Optionally, the processing device 2000 also includes a second processing module (not shown in the figure), which is used to: replace the first initial node in the second syntax tree with a first target node, the first initial operation involved in the first initial node is related to the identity information in the first platform, and the first replacement operation involved in the first target node is related to the identity information in the second platform. The second platform supports the deployment of the target contract, and the target contract is determined based on the source contract.

[0509] Optionally, the second processing module is specifically used to: replace the first initial node with the first target node according to a mapping relationship between multiple candidate initial operations and multiple candidate replacement operations, the first initial operation belongs to multiple candidate initial operations, and the first replacement operation belongs to multiple candidate replacement operations.

[0510] Optionally, the processing device 2000 further includes a second processing module, configured to embed an authority control code into the target contract, where the authority control code is used to describe the authority relationship corresponding to the identity information in the first platform.

[0511] Optionally, the processing device 2000 also includes a second processing module, used to: replace the second initial node in the second syntax tree with a second target node, the second initial node corresponds to the first initial syntax element in the source language, the second target node corresponds to the first target syntax element in the target language, the source language is the programming language of the source contract, and the target language is the programming language of the target contract.

[0512] Optionally, the second processing module is specifically used to: replace the second initial node with the second target node according to the mapping relationship between multiple candidate initial grammatical elements and multiple candidate target grammatical elements, the first initial grammatical element belongs to multiple candidate initial grammatical elements, and the first target grammatical element belongs to multiple candidate target grammatical elements.

[0513] Optionally, the programming language adopted by the source contract is an internal domain-specific language with Java as the host language.

[0514] Optionally, the syntax of the programming language adopted by the source contract includes the syntax of the Java language and an extended syntax, the extended syntax is related to the field of smart contracts, and the extended syntax includes at least one of the following: keywords, data types, built-in variables or built-in functions.

[0515] Optionally, the built-in functions in the extended syntax include: a function for converting an object into a script object notation JSON string, and / or a function for converting a JSON string into an object.

[0516] Optionally, the processing device 2000 also includes a second acquisition module (not shown in the figure) for acquiring the tag sequence of the source contract; a third processing module (not shown in the figure) for: converting the tag of the target keyword in the tag sequence into a Java annotation corresponding to the target keyword to obtain a processed tag sequence, where the target keyword belongs to a keyword in the extended grammar; generating a third syntax tree based on the processed tag sequence; replacing the third initial node in the third syntax tree with a grammar interface corresponding to the third initial node to obtain a first syntax tree, where the grammar interface corresponding to the third initial node is implemented based on the underlying call application program interface API of the first platform, the third initial node involves extended grammar, and the first platform supports Java language.

[0517] For detailed description, please refer to the method 500, method 200 and method 600 mentioned above, which will not be repeated here.

[0518] Each module in the processing device 2000 can be implemented by software or hardware. For example, the implementation of the first processing module 2020 will be described below, taking the first processing module 2020 as an example. Similarly, the implementation of other modules can refer to the implementation of the first processing module 2020.

[0519] As an example of a software functional unit, the first processing module 2020 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the first processing module 2020 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0520] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0521] As an example of a hardware functional unit, the first processing module 2020 may include at least one computing device, such as a server. Alternatively, the first processing module 2020 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0522] The multiple computing devices included in the first processing module 2020 can be distributed in the same region or in different regions. The multiple computing devices included in the first processing module 2020 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the first processing module 2020 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0523] It should be noted that, in other embodiments, the first processing module 2020 can be used to execute any step in the processing method of the smart contract, and the first acquisition module 2010 can be used to execute any step in the processing method of the smart contract. The steps that each module is responsible for implementing can be specified as needed, and all functions of the processing device 2000 are realized by implementing different steps in the processing method of the smart contract through each module.

[0524] This application also provides a computing device 1000. As shown in FIG15 , computing device 1000 includes a bus 1002, a processor 1004, a memory 1006, and a communication interface 1008. Processor 1004, memory 1006, and communication interface 1008 communicate with each other via bus 1002. Computing device 1000 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 1000.

[0525] Bus 1002 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG9 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 1002 may include a path for transmitting information between various components of computing device 1000 (e.g., memory 1006, processor 1004, and communication interface 1008).

[0526] The processor 1004 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0527] The memory 1006 may include volatile memory, such as random access memory (RAM). The processor 1004 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0528] Memory 1006 stores executable program code, which processor 1004 executes to implement the functions of first acquisition module 2010 and first processing module 2020, thereby implementing the smart contract processing method. In other words, memory 1006 stores instructions for executing the smart contract processing method.

[0529] The communication interface 1008 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1000 and other devices or a communication network.

[0530] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0531] As shown in Figure 16, the computing device cluster includes at least one computing device 1000. The memory 1006 in one or more computing devices 1000 in the computing device cluster may store the same instructions for executing the processing method of the smart contract.

[0532] In some possible implementations, the memory 1006 of one or more computing devices 1000 in the computing device cluster may also store partial instructions for executing the processing method of the smart contract. In other words, the combination of one or more computing devices 1000 can jointly execute the instructions for executing the processing method of the smart contract.

[0533] It should be noted that the memory 1006 in different computing devices 1000 in the computing device cluster can store different instructions, each for executing a portion of the functions of the smart contract processing device. In other words, the instructions stored in the memory 1006 in different computing devices 1000 can implement the functions of one or more modules in the first acquisition module 2010 and the first processing module 2020.

[0534] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network, which may be a wide area network or a local area network.

[0535] FIG17 illustrates a possible implementation. As shown in FIG17 , two computing devices 1000A and 1000B are connected via a network. Specifically, the connection to the network is achieved via a communication interface within each computing device. In this possible implementation, the memory 1006 within computing device 1000A stores instructions for executing the functions of the first acquisition module 2010. Simultaneously, the memory 1006 within computing device 1000B stores instructions for executing the functions of the first processing module 2020.

[0536] The connection method between the computing device clusters shown in Figure 17 can be considered to be that the processing method of the smart contract provided in this application may require data storage, so it is considered to hand over the functions implemented by the first processing module 2020 to the computing device 1000B for execution.

[0537] It should be understood that the functions of the computing device 1000A shown in FIG17 may also be completed by multiple computing devices 1000. Similarly, the functions of the computing device 1000B may also be completed by multiple computing devices 1000.

[0538] The present application also provides a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute a smart contract processing method.

[0539] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the processing method of the smart contract.

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

[0541] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0542] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0544] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0545] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the processing method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0546] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for processing a smart contract of a blockchain, characterized in that: The processing method comprises: Get the first syntax tree corresponding to the source contract; identifying a risk node in the first syntax tree, the risk node involving a risky operation; Perform at least one of the following processing on the first syntax tree to obtain a second syntax tree: replacing a first risk node in the risk nodes with a first safety node, the first risk node involving a first risk operation, the first safety node involving a first safety operation, the first safety operation being used to replace the first risk operation; or, Add a permission detection condition for a second risk node in the risk nodes, wherein the permission detection condition is used to determine the identity of the caller when the function indicated by the second risk node is called.

2. The processing method according to claim 1, characterized in that: The performing at least one of the following processing on the first syntax tree further includes: when the risk node includes a third risk node, throwing exception indication information based on the third risk node.

3. The processing method according to claim 1 or 2, characterized in that: The processing method is applied in a compiler.

4. The processing method according to claim 3, characterized in that: The processing method further includes: when the risk node includes the third risk node, refusing to pass the compilation process of the source contract.

5. The processing method according to any one of claims 2 to 4, characterized in that: The third risk node does not have an uncertainty annotation, or the processing method includes: When the risk node includes the third risk node and the third risk node has an uncertainty annotation, no exception indication information is thrown based on the third risk node.

6. The processing method according to any one of claims 1 to 5, characterized in that: The replacing the first risk node in the risk nodes with the first safety node includes: replacing the first risk node with the first safety node according to a mapping relationship between multiple candidate risk operations and multiple candidate safety operations, the first risk operation belongs to the multiple candidate risk operations, and the first safety operation belongs to the multiple candidate safety operations.

7. The processing method according to any one of claims 1 to 6, characterized in that: The processing method also includes: A first initial node in a second syntax tree is replaced with a first target node, wherein a first initial operation involved in the first initial node is related to identity information in a first platform, and a first replacement operation involved in the first target node is related to identity information in a second platform, and the second platform supports deployment of a target contract, and the target contract is determined based on the source contract.

8. The processing method according to claim 7, characterized in that: The step of replacing the first initial node in the second syntax tree with the first target node comprises: The first initial node is replaced with the first target node according to a mapping relationship between multiple candidate initial operations and multiple candidate replacement operations, the first initial operation belongs to the multiple candidate initial operations, and the first replacement operation belongs to the multiple candidate replacement operations.

9. The processing method according to claim 7 or 8, characterized in that: The processing method also includes: An authority control code is embedded in the target contract, and the authority control code is used to describe the authority relationship corresponding to the identity information in the first platform.

10. The processing method according to any one of claims 7 to 9, characterized in that: The processing method also includes: Replace the second initial node in the second syntax tree with a second target node, wherein the second initial node corresponds to the first initial syntax element in the source language, and the second target node corresponds to the first target syntax element in the target language, wherein the source language is the programming language of the source contract, and the target language is the programming language of the target contract.

11. The processing method according to claim 10, characterized in that: The step of replacing the second initial node in the second syntax tree with the second target node comprises: According to a mapping relationship between multiple candidate initial grammar elements and multiple candidate target grammar elements, the second initial node is replaced by the second target node, the first initial grammar element belongs to the multiple candidate initial grammar elements, and the first target grammar element belongs to the multiple candidate target grammar elements.

12. The processing method according to any one of claims 1 to 11, characterized in that: The programming language used by the source contract is an internal domain-specific language using Java as the host language.

13. The processing method according to claim 12, characterized in that: The syntax of the programming language adopted by the source contract includes the syntax of the Java language and an extended syntax, wherein the extended syntax is related to the field of smart contracts, and the extended syntax includes at least one of the following: a keyword, a data type, a built-in variable, or a built-in function.

14. The processing method according to claim 13, characterized in that: The built-in functions in the extended syntax include: a function for converting an object into a script object notation Json string, and / or a function for converting a Json string into an object.

15. The processing method according to claim 13 or 14, characterized in that: The processing method also includes: Obtaining a tag sequence of the source contract; Converting a tag of a target keyword in the tag sequence into a Java annotation corresponding to the target keyword to obtain a processed tag sequence, wherein the target keyword belongs to a keyword in the extended grammar; generating a third syntax tree based on the processed token sequence; The third initial node in the third syntax tree is replaced with the syntax interface corresponding to the third initial node to obtain the first syntax tree, wherein the syntax interface corresponding to the third initial node is implemented based on the underlying application programming interface API of the first platform, the third initial node involves the extended syntax, and the first platform supports Java language.

16. A processing device for a blockchain smart contract, characterized in that: The processing device comprises: A first acquisition module, used to acquire a first syntax tree of a source contract; The first processing module is used for: identifying a risk node in the first syntax tree, the risk node involving a risky operation; Perform at least one of the following processing on the first syntax tree to obtain a second syntax tree: replacing a first risk node in the risk nodes with a first safety node, the first risk node involving a first risk operation, the first safety node involving a first safety operation, the first safety operation being used to replace the first risk operation; or, Add a permission detection condition for a second risk node in the risk nodes, wherein the permission detection condition is used to determine the identity of the caller when the function indicated by the second risk node is called.

17. The processing device according to claim 16, characterized in that The first processing module is further configured to: when the risk node includes a third risk node, throw out abnormal indication information based on the third risk node.

18. The processing device according to claim 16 or 17, characterized in that The processing device is applied in a compiler.

19. The processing device according to claim 18, characterized in that The first processing module is further used for: refusing to pass the compilation process of the source contract when the risk node includes the third risk node.

20. The processing device according to any one of claims 17 to 19, characterized in that The third risk node does not have an uncertainty annotation, or the first processing module is used to: When the risk node includes the third risk node and the third risk node has an uncertainty annotation, no exception indication information is thrown based on the third risk node.

21. The processing device according to any one of claims 16 to 20, characterized in that The first processing module is specifically used to: replace the first risk node with the first safety node according to a mapping relationship between multiple candidate risk operations and multiple candidate safety operations, the first risk operation belongs to the multiple candidate risk operations, and the first safety operation belongs to the multiple candidate safety operations.

22. The processing device according to any one of claims 16 to 21, characterized in that The processing device further includes a second processing module, configured to: A first initial node in a second syntax tree is replaced with a first target node, wherein a first initial operation involved in the first initial node is related to identity information in a first platform, and a first replacement operation involved in the first target node is related to identity information in a second platform, and the second platform supports deployment of a target contract, and the target contract is determined based on the source contract.

23. The processing device according to claim 22, characterized in that The second processing module is specifically used for: The first initial node is replaced with the first target node according to a mapping relationship between multiple candidate initial operations and multiple candidate replacement operations, the first initial operation belongs to the multiple candidate initial operations, and the first replacement operation belongs to the multiple candidate replacement operations.

24. The processing device according to claim 22 or 23, characterized in that The processing device further includes a second processing module, configured to: An authority control code is embedded in the target contract, and the authority control code is used to describe the authority relationship corresponding to the identity information in the first platform.

25. The processing device according to any one of claims 22 to 24, characterized in that The processing device further includes a second processing module, configured to: Replace the second initial node in the second syntax tree with the second target node, wherein the second initial node corresponds to the first initial node in the source language Syntax element, the second target node corresponds to the first target syntax element in the target language, the source language is the programming language of the source contract, and the target language is the programming language of the target contract.

26. The processing device according to claim 25, characterized in that The second processing module is specifically used for: According to a mapping relationship between multiple candidate initial grammar elements and multiple candidate target grammar elements, the second initial node is replaced by the second target node, the first initial grammar element belongs to the multiple candidate initial grammar elements, and the first target grammar element belongs to the multiple candidate target grammar elements.

27. A processing device according to any one of claims 16 to 26, characterized in that The programming language used by the source contract is an internal domain-specific language using Java as the host language.

28. The processing device according to claim 27, characterized in that The syntax of the programming language adopted by the source contract includes the syntax of the Java language and an extended syntax, wherein the extended syntax is related to the field of smart contracts, and the extended syntax includes at least one of the following: a keyword, a data type, a built-in variable, or a built-in function.

29. The processing device according to claim 28, characterized in that The built-in functions in the extended syntax include: a function for converting an object into a script object notation Json string, and / or a function for converting a Json string into an object.

30. The processing device according to claim 28 or 29, characterized in that The processing device further includes a second acquisition module, configured to acquire a tag sequence of the source contract; The third processing module is used for: Converting a tag of a target keyword in the tag sequence into a Java annotation corresponding to the target keyword to obtain a processed tag sequence, wherein the target keyword belongs to a keyword in the extended grammar; generating a third syntax tree based on the processed token sequence; The third initial node in the third syntax tree is replaced with the syntax interface corresponding to the third initial node to obtain the first syntax tree, wherein the syntax interface corresponding to the third initial node is implemented based on the underlying application programming interface API of the first platform, the third initial node involves the extended syntax, and the first platform supports Java language.

31. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 15.

32. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 15.

33. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster is caused to perform the method according to any one of claims 1 to 15.

Images