Processing method and processing device for smart contract of block chain

Abstract

The invention provides a processing method and a processing device for a smart contract of a block chain. The processing method comprises the following steps: acquiring a first syntax tree corresponding to a source contract; identifying a risk node in the first syntax tree, wherein the risk node relates to a risk operation; executing 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 security node, the first risk node relating to a first risk operation, the first security node relating to a first security operation, and the first security operation being used for replacing the first risk operation; or, a permission detection condition is added to the second risk node in the risk nodes, and the permission detection condition is used for judging the identity of the caller when the function indicated by the second risk node is called. According to the scheme of the embodiment of the invention, the security of the smart contract is improved.

Description

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on September 25, 2023, with application number 202311243785.0, and invention name “Method and device for processing domain-specific languages”, all contents of which are incorporated by reference in 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 transfer and exchange in untrusted networks, effectively solving the problem of data flow fraud in traditional transactions. Smart contracts are executable codes that can be deployed on blockchains, which can automatically execute contracts on behalf of all parties without relying on a central agency. With the continuous development of smart contract technology, the supported scenarios are gradually increasing, the business logic is becoming more complex, and the smart contract language is gradually exposing a series of limitations.

[0004] In recent years, vulnerabilities related to smart contracts have emerged one after another, bringing security risks to upper-level applications. Insecure smart contracts can undermine the stability of the blockchain and infringe on the security of users' assets. In addition, compared with other programs, smart contracts that have been deployed on the blockchain are difficult to modify. Once a vulnerability is targeted, it may cause huge losses.

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

[0006] The present application provides a method and device for processing smart contracts on a blockchain, which are beneficial to improving the security of smart contracts.

[0007] 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 security node, the first risk node involving a first risk operation, the first security node involving a first security operation, the first security operation being used to replace the first risk operation; or, 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.

[0008] 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, the risk node in the first syntax tree can be replaced with the corresponding security node to replace the risk operation with the corresponding security operation, which is beneficial to reducing loopholes 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 identity of the caller is legal during operation, which is beneficial to improving the security of the contract operation and avoiding permission control loopholes.

[0009] At the same time, the solution of the embodiment of the present application is conducive to reducing the processing required by users at the code level, simplifying the coding process, reducing usage costs, and improving development efficiency. Moreover, this can also reduce the learning threshold for contract development, thereby improving the ease of use of the language.

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

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

[0012] In combination with the first aspect, in some 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.

[0013] 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 handle it.

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

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

[0016] 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 helping to improve the security of the contract.

[0017] 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 uncertain vulnerabilities in any scenario.

[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 second risk set, the second risk set includes risk operations that may cause uncertainty vulnerabilities in some scenarios, and 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.

[0019] 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 a third risk node and the third risk node has an uncertainty annotation, no exception indication information is thrown based on the third risk node.

[0020] In the scheme 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.

[0021] 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 a 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.

[0022] In combination with the first aspect, in certain implementations of the first aspect, the processing method also includes: replacing a 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 a target contract, and the target contract is determined based on the source contract.

[0023] In the solution of the embodiment of the present application, a smart contract written in a source language can be converted 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. Specifically, operations related to the identity in platform #2 are converted into operations related to the identity in platform #3, which realizes the processing of the difference in identity information between platform #2 and platform #3, thereby facilitating the migration of smart contracts between different operating environments.

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

[0025] 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, the permission control code being used to describe the permission relationship corresponding to the identity information in the first platform.

[0026] Exemplarily, the permission control code may be embedded in the target contract in the form of a comment.

[0027] In an embodiment of the present application, a permission control code is embedded in the target contract, and the user 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.

[0028] In combination with the first aspect, in certain implementations of the first aspect, the processing method also 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.

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

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

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

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

[0033] In combination with the first aspect, in certain implementations of the first aspect, 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.

[0034] In the embodiment of the present application, the extended syntax is related to the field of smart contracts, which makes the DSL of the embodiment of the present application focus on the field of smart contracts, improves the comprehensibility of the language syntax, and thus improves the ease of use for smart contract development. At the same time, the improvement of the comprehensibility of the language syntax is conducive to lowering the learning threshold of users, thereby reducing the generation of error codes and improving user experience.

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

[0036] In 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. 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, more in line with the user's coding habits, reducing the amount of handwritten code by the user, and further improving ease of use, which is conducive to improving user experience.

[0037] 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, wherein 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 the first syntax tree, wherein 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.

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

[0039] In a second aspect, a method for processing smart contracts 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 involving the first initial node is related to identity information in a first platform, and a first replacement operation involving 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.

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

[0041] In combination with the second aspect, in certain implementations of the second aspect, the processing method further includes: embedding an authority control code into the target contract, the authority control code being used to describe the authority relationship corresponding to the identity information in the first platform.

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

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

[0044] 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 a 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 for 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 when the risk node includes a third risk node, throwing an exception indication information based on the third risk node.

[0045] 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 adopted by the source contract is an internal domain-specific language with Java as the host language, 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; 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, the target keyword belongs to the keyword 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.

[0046] 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 simplified notation Json string, and / or a function for converting a Json string into an object.

[0047] In a fourth aspect, a method for processing smart contracts of 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.

[0048] In the fifth aspect, a processing device for smart contracts of a blockchain is provided. The processing device may include modules corresponding to 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 a hardware circuit and software.

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

[0050] In a sixth aspect, a computing device cluster is provided, comprising at least one computing device, each computing device comprising a processor and a memory. The processor of at least one computing device is used to execute instructions stored in the memory of at least one computing device, so that the computing device cluster executes the method in any one of the implementations of the first aspect to the fourth aspect.

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

[0052] 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

[0053] Figure 1 is a schematic flow chart of a method for processing a smart contract in an embodiment of the present application;

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

[0055] Figure 3 is a schematic block diagram of the architecture of a precompiler according to an embodiment of the present application;

[0056] Figure 4 is a schematic diagram of a workflow of a precompiler in an embodiment of the present application;

[0057] Figure 5 is a schematic flow chart of another method for processing a smart contract in an embodiment of the present application;

[0058] Figure 6 is a schematic flow chart of another method for processing a smart contract in an embodiment of the present application;

[0059] Figure 7 It is a schematic diagram of a smart contract template of an embodiment of the present application;

[0060] Figure 8 is a schematic block diagram of another architecture of a precompiler according to an embodiment of the present application;

[0061] Fig. 9 is a schematic diagram of the workflow of another precompiler in an embodiment of the present application;

[0062] Fig.10 It is a schematic diagram of the workflow of a grammar parsing module in an embodiment of the present application;

[0063] Fig.11 is a schematic diagram of a workflow of a vulnerability prevention module in an embodiment of the present application;

[0064] Fig.12 is a schematic diagram of a workflow of a platform transplantation module in an embodiment of the present application;

[0065] Fig.13 It is a schematic block diagram of an operating environment of a smart contract in an embodiment of the present application;

[0066] Fig.14 is a schematic block diagram of a processing device for a smart contract according to an embodiment of the present application;

[0067] Fig.15 is a schematic block diagram of a computing device according to an embodiment of the present application;

[0068] Fig.16 is a schematic block diagram of a computing device cluster according to an embodiment of the present application;

[0069] Fig.17 It is a schematic block diagram of another computing device cluster according to an embodiment of the present application. DETAILED DESCRIPTION

[0070] The terms used in the following embodiments are only for the purpose of describing specific embodiments, and are not intended to be used as limitations to the present application. As used in the specification and the appended claims of the present application, the singular expressions "one", "a kind of" and "the" are intended to include, for example, "one or more" such expressions, unless there is a clear contrary indication in the context. It should also be understood that in the following embodiments of the present application, "at least one", "at least one", "one or more" refer to one, two or more. "First", "second" and various digital numbers are only for the convenience of describing the distinction, and are not used to limit the scope of the embodiments of the present application. "And / or" is used to describe the corresponding relationship of the corresponding objects, indicating that there can be three kinds of relationships, for example, "A and / or B" can represent: only A exists, only B exists, and there are three kinds of A and B at the same time, wherein A and B can be singular or plural. The character " / " generally indicates that the objects associated with each other are an "or" relationship. The size of the sequence number of each process below does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present 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.

[0071] References to "one embodiment" or "some embodiments" described 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 the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific 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 refer to the device making corresponding processing under certain objective circumstances, not limiting the time, and not requiring the device to have a judgment action when implementing, nor implying the existence of other limitations.

[0072] In the present application, "used for indication" may include being used for direct indication and being used for indirect indication. When describing that a certain indication information is used for indicating A, it may include that the indication information directly indicates A or indirectly indicates A, but it does not mean that the indication information must carry A.

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

[0074] (1) Blockchain;

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

[0076] (2) Smart contracts;

[0077] 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 agency.

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

[0079] Hyperledger is an open source framework for alliance chains. It has good performance, highly modular and configurable architecture, complete member management and access control, and is suitable for building flexible and high-quality enterprise alliance blockchain systems for multiple industries.

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

[0081] Smart contract programming languages ​​can be divided into two categories: one is domain specific language (DSL), and the other is general programming language.

[0082] A domain specific language is a programming language that focuses on a specific domain but has limited expressive power. DSL can be divided into three categories: external DSL, internal DSL, and language workbench.

[0083] 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 interpretation or compilation tools in the stages of lexical analysis, syntax analysis, code generation, etc. For example, the Solidity language of the Ethereum platform has domain-specific syntax for smart contracts and an independent compiler for the language itself.

[0084] 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 DSL focuses on important concepts in a specific domain, abstracts some implementation and technical details, and only exposes really important information. Therefore, the syntax is usually more concise, easier to understand and analyze, and allows developers to communicate better with domain experts, improving productivity. In addition, DSL can decouple domain logic and technology and enable them to develop separately. Domain logic has its own value and should be retained, which makes the investment in writing code using DSL more valuable.

[0085] External DSLs have some inherent disadvantages. First, it is difficult to achieve both ease of use and security. Turing-complete DSLs, represented by Solidity, have the ability to develop smart contracts with complex logic, but have obvious disadvantages in terms of security. Turing-incomplete DSLs, represented by Vyper, circumvent security issues by removing some dangerous syntax, but this also limits the expressive power of the language itself. Second, since DSLs have relatively few application scenarios, they have many limitations in design, which brings inconvenience to development. For example, there are insufficient general method libraries and standard interfaces, and there is a lack of additional functions, such as error reporting and logging, which affects development efficiency. Third, there are fewer community resources. Smart contracts are not very popular in the industry. Even for Solidity, the most popular smart contract DSL, the number of related code libraries that can be retrieved on GitHub is about 100 times that of Java. Fewer community resources means that the entry-level learning threshold is high, which is not conducive to problem solving when encountering confusion during contract writing. 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.

[0086] Internal DSL, also known as embedded DSL, uses an existing programming language as the host language, and supplements the host language with various syntax and semantics for specific fields to extend the host language. The host language is a programming language selected and grammatically extended by the internal domain-specific language. The implementation of internal DSL does not require the design of language grammar and compiler from scratch. The host language can be used to analyze and model specific domain problems, and the compilation mechanism of the host language can be combined. The difference between internal DSL and external DSL lies mainly in the implementation principle, and the difference in presentation effect is not large.

[0087] 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 syntax and semantic sets with less effort, thereby supporting efficient program development. LWB constitutes a multi-paradigm and language-oriented programming environment to solve challenges in software engineering. The functions of LWB 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, model and language testing and debugging, and support the combination of multiple defined languages ​​in different aspects. LWB is usually used to define the rules of models and languages ​​for the application fields of key software components, and 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.

[0088] General programming languages ​​can be divided into two categories. The first category is to directly expand and encapsulate the API of the underlying operations of blockchain and smart contracts based on the native language, and the second category is to modify the native language to make it more suitable for the field of smart contracts.

[0089] The principle of native general-purpose language to support the development of smart contracts is to expand and encapsulate the third-party libraries related to the underlying blockchain on its basis to provide APIs for operating smart contracts. There are many natural advantages to using general-purpose language to develop contracts. First, general-purpose language has a wider range of user groups, which reduces the learning cost for developers in other fields to get started with smart contract development and accelerates the application of blockchain solutions in various fields. Second, general-purpose language is usually accompanied by its rich ecological tools and huge community resources. Finally, general-purpose language has a large number of support libraries and provides many general features, which provides general solutions for typical programming problems and can be easily applied to the development of smart contracts. For example, Go, Java and JavaScript support the development of smart contracts on the HF platform by providing relevant third-party libraries. However, the native general-purpose language is not tailored for smart contracts, so when it is used in smart contract scenarios, it lacks adaptability and has the following shortcomings. First, the syntax of general-purpose language is relatively lengthy and complicated compared to DSL, and a large number of third-party libraries need to be introduced during development, which increases the difficulty of writing. Second, although the general-purpose language is relatively safe in design, it is still difficult to fully meet the specific security requirements in smart contract scenarios, such as 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 bring some security risks and may cause a waste of space resources.

[0090] Since there are many shortcomings in developing smart contracts using native general-purpose languages, some scholars have already made modifications based on native languages ​​according to the characteristics of the smart contract field. Generally speaking, the modified language is a subset of the native language. Existing work focuses on modifying Java. For example, Hotmoka only allows the use of whitelisted methods and libraries from the standard Java library to avoid inconsistent contract execution results caused by the uncertainty of the Java language. Corda provides a minimum set of Java libraries to verify contracts. NEO also ensures security as much as possible by restricting the call to Java libraries. In fact, many Java support libraries are uncertain, and for most blockchains, uncertainty will affect the consensus of each node on the contract execution results, resulting in forks in the blockchain network. In HF, if the code execution is uncertain, the transaction will be rejected. While retaining most of the advantages of the general-purpose language itself, the existing modification scheme improves its widespread uncertainty and eliminates unnecessary mechanisms in the native language for smart contract scenarios. However, at this stage, the modification of the general-purpose language is mainly to weaken its functions, so the optimization space is still very limited.

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

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

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

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

[0095] (7) Concept mapping;

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

[0097] (8) Procedural uncertainty;

[0098] A nondeterministic program may produce different outputs when run twice when given the same input.

[0099] (9) Uncertainty loopholes;

[0100] Uncertainty vulnerabilities are vulnerabilities that cause program uncertainty. In blockchain, uncertainty vulnerabilities can cause nodes in the network to have inconsistent understandings of ledger data, thereby causing security issues such as forks.

[0101] (10) Permission access control vulnerabilities;

[0102] When unauthorized users in an application can access functions or variables that they should not have access to, there will be a permission access control vulnerability, or permission control vulnerability. Since smart contracts in blockchain are difficult to modify once they are on the chain, this vulnerability is particularly fatal in the field of smart contracts.

[0103] Blockchain provides a trusted channel for information and value transfer and exchange in untrusted networks, effectively solving the problem of data flow fraud in traditional transactions. Smart contracts are executable codes that can be deployed on blockchains, which can automatically execute contracts on behalf of all parties without relying on central agencies. With the continuous development of smart contract technology, the supported scenarios are gradually increasing, involving multiple application fields such as finance, supply chain, Internet of Things, and public management. At the same time, the business logic that needs to be processed is becoming more and more complex, and the smart contract language is gradually exposing a series of limitations.

[0104] Writing contracts in a language that is easy to use, easy to learn, and easy to understand is the common expectation of practitioners with different development experience, but existing programming languages ​​cannot meet this demand. DSL in the field of smart contracts has advantages such as concise syntax, easy to understand and easy to analyze, but it also has some disadvantages. Taking external DSL as an example, external DSL has some inherent disadvantages. First, it is difficult to have both ease of use and security. Turing complete DSL represented by Solidity has the ability to develop smart contracts with complex logic, but has obvious disadvantages in security. Turing incomplete DSL represented by Vyper circumvents security issues by deleting some dangerous syntax, but this also limits the expressive power of the language itself. Second, since DSL has relatively few application scenarios, it has many limitations in design, which brings inconvenience to development. For example, there are insufficient general method libraries and standard interfaces, and lack of additional functions, such as error reporting and logging, which affects development efficiency. Third, there are fewer community resources. Smart contracts are not very popular in the industry. Even for Solidity, the most popular smart contract DSL, the number of relevant code libraries that can be retrieved on GitHub is about 100 times that of Java. The lack of community resources means that the entry learning threshold is high, which is not conducive to solving problems when encountering confusion during the contract writing process. Fourth, the current ecosystem of smart contract DSL is not perfect, such as the lack of a complete interactive integrated development environment (IDE), debugger, and debugging tools.

[0105] The current programming languages ​​in the smart contract field are not easy to use and cannot meet the needs of users. The DSL in the smart contract field lacks general libraries and standard interfaces, and lacks additional functions such as error reporting. At the same time, the ecological construction of programming languages ​​is not perfect, and there are few community resources and surrounding documents, which makes it difficult to support efficient and standardized development of smart contracts.

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

[0107] In view of this, an embodiment of the present application provides a design framework for a domain-specific language developed for the smart field. The design framework includes an extended syntax definition and a precompiler. Specifically, the domain-specific language proposed in the embodiment of the present application is an internal DSL with Java language as the host language. The internal DSL expands the syntax definition of the smart contract field on the basis of Java language, enhances the definition of the smart contract field, and thus improves the ease of use of the programming language in the smart contract field. The precompiler can be used to perform syntax parsing on the smart contract developed using the DSL of the embodiment of the present application to ensure that the extended syntax is compilable.

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

[0109] Method 100 is applied to the development stage of smart contracts. The programming language of smart contracts is an internal DSL with Java as the host language. The internal DSL provided in the embodiment of the present application can be called JSmarter. That is, JSmarter is an internal DSL for the field of smart contracts with Java as the host language.

[0110] The syntax of JSmarter includes the syntax of the Java language and the extended syntax, and the extended syntax is related to the field of smart contracts.

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

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

[0113] like Figure 1 As shown, method 100 may include the following steps.

[0114] 110, displaying the code editing interface.

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

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

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

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

[0119] 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 a ledger, or modifying a function that can write a ledger, etc.

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

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

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

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

[0124] Exemplarily, the extended built-in functions are used to perform operations in the field of smart contracts.

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

[0126] 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. The JavaScript object notation is the JS object notation.

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

[0128] 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 Java native syntax, JSmarter extends 6 keywords, 1 data type, 3 built-in variables, and 10 built-in functions for the smart contract field.

[0129] Table 1

[0130]

[0131] It should be understood that the extended syntax shown in Table 1 is only an example and does not constitute a limitation on 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, in traditional application fields, Java language is easy to use. Using Java language as the host language can greatly reduce the learning threshold for users. At the same time, Java language is the most commonly used programming language by developers in open source projects, with a huge user base and a complete community ecology. Internal DSL based on Java language can be developed using the existing Java tool chain, reducing the difficulty of development. Moreover, many blockchain platforms support the development of smart contracts using Java language.

[0134] Smart contracts written using internal DSL are also legal host language programs, so the solution of this application can be developed using Java's standard tool chain. This helps lower the learning threshold for users, thereby reducing the generation of error codes and improving user experience. Moreover, JSmarter combines the advantages of Java language with a large user base and mature supporting tools, providing general solutions to common programming problems.

[0135] In the embodiment of the present application, the extended syntax in JSmarter is related to the field of smart contracts, covering concepts unique to the field of smart contracts, such as account operations, account addresses, and endorsement policies. This allows the DSL of the embodiment of the present application to focus on the field of smart contracts, improve the comprehensibility of the language grammar, and thus improve the ease of use for smart contract development. At the same time, the improvement of the comprehensibility of the language grammar is conducive to lowering the learning threshold for users, thereby reducing the generation of error codes and improving user experience.

[0136] At the same time, in the scheme 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. Exemplarily, 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 the conversion between json strings and objects. The scheme of the embodiment of the present application provides two built-in functions, obj2Json and json2Obj. Users can directly call these two functions to implement the conversion between json strings and objects, which simplifies the conversion process, is more in line with the coding habits of users, and further improves ease of use, which is conducive to improving user experience. The scheme 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 A method for processing a smart contract provided in an embodiment of the present application is shown, which can process a smart contract developed using JSmarter to ensure that the smart contract can be compiled.

[0139] Figure 2 The method 200 shown may be performed by a precompiler. The precompiler may be used to process a 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 character stream of JSmarter. The programming language of the source contract can be referred to as the source language.

[0141] Outputting the target contract can be understood as outputting the character stream of the target contract, or in other words, outputting the code of the target contract. The character stream of the target contract is the character stream of the programming language of the target contract. The programming language of the target contract 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 may be represented as a character stream of Java. The input of the precompiler may be a character stream of JSmarter, and the output of the precompiler may be a character stream of Java.

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

[0144] It should be understood that the above is only an example, and the programming language of the target contract can also be other programming languages, which is not limited in the present application embodiment. For ease of description, in method 200, the target language is mainly Java language as an example for description. For the case where the target language is other programming languages, reference can be made to method 600 below, which is not described 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. The output of the precompiler may be used as the input of the compiler.

[0148] Taking Java as an example, the precompiler outputs the target contract, which is a character stream of the Java language, and the Java compiler parses the target contract to output the bytecode corresponding to the target contract. 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 inside the blockchain platform, and directly called by the node inside 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 independent of the blockchain platform in an environment other than the blockchain platform. For example, the external chain code can be run as a service.

[0155] Exemplarily, the compilation of external chain codes and the configuration and construction of related services can be implemented through the middleware of the blockchain platform. Taking Kubernetes as an example, the middleware can include an external builder and launcher of HF. When it is necessary to call the target contract, the peer node can start and call the external chain code through the middleware.

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

[0157] For the sake of ease of description, the embodiments of the present 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 the present application.

[0158] Figure 3 A schematic diagram showing the architecture of a precompiler according to an embodiment of the present application is shown.

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

[0160] For example, Figure 3 As shown, the source contract is input into the syntax parsing module 310. The syntax parsing module 310 can be used to perform syntax parsing on the source contract to generate AST. Performing syntax parsing on the source contract means performing syntax parsing on the code of the source contract. Specifically, the syntax parsing module 310 can be used to perform lexical analysis and syntax analysis on the source code to generate AST#2.

[0161] Further, optionally, the precompiler 300 may also include a code generation module 330. The code generation module 330 acts on the code generation stage. The code generation module 330 may be used to generate a target contract based on AST#2, that is, to generate a character stream of the target language, for example, Figure 3 Character streams in Java.

[0162] For example, Figure 2 The illustrated method 200 may be performed by a precompiler 300 .

[0163] like Figure 2 As shown, method 200 includes the following steps. Among them, step 210 and step 220 can be regarded as the lexical analysis stage. Step 230 and step 240 can be regarded as the syntax analysis stage.

[0164] 210, obtain 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, source code token sequences 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, Figure 4 As shown, the syntax parsing module can identify the token of the target keyword and generate the corresponding Java annotation.

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

[0175] Table 2

[0176] Keywords annotation contract @Contact struct @Struct view @View payable @Payable

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

[0178] 230, get AST#1.

[0179] In the case where the target keyword is not included in the source code, AST#1 may be generated based on the token sequence of the source code obtained in step 210 .

[0180] In the case where the target keyword is included in the source code, 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 embodiment of the present application is mainly described by taking the processed token sequence as an example, and does not limit the solution of the embodiment of the present application.

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

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

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

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

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

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

[0187] For example, blockchain platform #1 can be used to deploy a smart contract based on the Java language. When the target contract is a Java character stream, blockchain platform #1 can be used to deploy the target contract. For example, the target contract is compiled into bytecode and then deployed on blockchain platform #1.

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

[0189] The tree node #1 relates to the extended grammar, that is, the tree node #1 belongs to the node corresponding to the extended grammar. The tree node #1 can be any tree node in the node 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.

[0190] In step 240, for the tree nodes in AST#1 involving the extended syntax, they can be mapped to the defined syntax interface implementation. For example, the tree nodes in AST#1 involving the Java annotations generated in step 220 (i.e., the Java annotations corresponding to the target keywords), the tree nodes involving the keywords replaced with other extended ones other than the Java annotations, the tree nodes involving the extended data types, the tree nodes involving the built-in variables, and the tree nodes involving the 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.

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

[0192] In step 240, the tree nodes in AST#1 are traversed, the tree nodes in AST#1 involving the extended grammar are identified, and they are mapped to the corresponding grammar interface. After all the tree nodes are traversed, AST#2 is output.

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

[0194] For example, Figure 4 As shown, the grammar parsing module 310 performs node recognition in AST#1 to identify the tree nodes of the designed extended grammar and maps them to the grammar interface.

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

[0196] Table 3

[0197]

[0198]

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

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

[0201] If the extended keywords in the source contract include other extended keywords in addition to the target keywords, the nodes corresponding to the extended keywords in AST#1 may include tree nodes modified by Java annotations corresponding to the target keywords and nodes corresponding to other extended keywords. Take the example that 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.

[0202] 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 specification of blockchain platform #1.

[0203] For example, Figure 4 As shown, the syntax parsing module 310 can process the Java annotations, for example, add, delete or modify the corresponding tree nodes.

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

[0205] In the above operation, the precompiler 300 can automatically and synchronously add the relevant import dependencies.

[0206] Furthermore, the method 200 may also include step 250 .

[0207] 250, generating a target contract based on AST#2, that is, generating a character stream of the target language.

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

[0209] 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, that is, the target contract.

[0210] 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 is conducive to reducing development costs.

[0211] The target language may also be other programming languages. When the target language is other programming languages, the method for generating the target contract may refer to method 600 described later, which will not be described in detail here.

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

[0213] 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 to reduce development costs.

[0214] In recent years, vulnerabilities related to smart contracts have emerged one after another, bringing security risks to upper-level applications. Insecure smart contracts will undermine the stability of the blockchain and infringe on the asset security of users. At the same time, compared with other programs, smart contracts that have been deployed on the blockchain are difficult to modify. Once the vulnerability is targeted, it may cause huge losses. Therefore, how to improve the security of smart contracts has become an urgent problem to be solved.

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

[0216] Figure 5 A schematic flowchart of another method for processing a smart contract according to an embodiment of the present application is shown. Figure 5 The method 500 shown can also be regarded as a method for preventing vulnerabilities applied in the field of smart contracts.

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

[0218] The vulnerability prevention device may also be deployed in other devices as a functional module of the other devices. In this case, the vulnerability prevention device may also be referred to as a vulnerability prevention module.

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

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

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

[0222] like Figure 5 As shown, method 500 may include the following steps.

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

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

[0225] Exemplarily, the AST#4 may be parsed by a compiler. For example, if the programming language of the source contract is Java, the compiler may be a Java compiler. For another example, if the programming language of the source contract is Solidity, the compiler may be a Solidity compiler.

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

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

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

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

[0230] At 520, tree nodes involving risky operations are identified in AST #4.

[0231] The 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.

[0232] It should be noted that the risk nodes in strategy #1, strategy #2 and strategy #3 in the following text can be identified together or separately.

[0233] For example, a risk operation library can be pre-set, which contains a variety of vulnerabilities and their characteristics at the code level. Risk operations in the security operation library, risk operations in the blacklist library, risk operations in the graylist library, and risk operations involving access rights are all risk operations related to vulnerabilities in the risk operation library. In this case, risk nodes can be identified in AST#4 based on the characteristics of the vulnerability at the code level, and all risk nodes can be marked, or all risk operations in the source contract can be marked. Then the marked risk nodes are processed based on different strategies.

[0234] For another example, the risk operations and their characteristics at the code level can be stored in the security operation library, blacklist library, graylist library, etc., respectively. 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.

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

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

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

[0238] Strategy #1: Replace.

[0239] 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), 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.

[0240] Risk node #1 is the node corresponding to risk operation #1. Safety node #1 is the node corresponding to safety operation #1.

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

[0242] In strategy #1, corresponding security operations can be set in advance for some risk operations. The security operation used to replace the risk operation can achieve the same function as the risk operation. 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 application does not limit this.

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

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

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

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

[0247] The representation form 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 form.

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

[0249] 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 the multiple candidate risk operation-related vulnerabilities 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 multiple candidate risk operation-related vulnerabilities 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.

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

[0251] Table 4

[0252] Vulnerability Type Corresponding safety operations Reentrancy Vulnerability Reentrant Lock Integer overflow vulnerability BigInteger Pseudo-random vulnerabilities True random number generator class (SecureRandom) Collection iteration order vulnerability Stable iterable collections (LinkedHashSet and LinkedHashMap)

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

[0254] It should be understood that Table 4 is only an example and does not limit the solution of the embodiment of the present application. For example, the risk operations related to the set iteration order vulnerability may include multiple risk operations, some of which can be replaced by the security operations in Table 4, and other risk operations may not be replaced by the security operations in Table 4. For risk operations that cannot be replaced, please refer to Table 5, which will not be described in detail here.

[0255] If there is a replaceable security operation in the security operation library for the risk operation in the source contract, the risk operation can be replaced with the corresponding security operation. In step 530, the risk operation can be replaced with the corresponding security operation by replacing the risk node in the AST with the corresponding security node. This helps to reduce vulnerabilities in the contract and thus improve the security of the contract.

[0256] Strategy #2: Report errors.

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

[0258] The abnormal indication information can be used to indicate that there are 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.

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

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

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

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

[0263] For example, the vulnerability prevention module is deployed in the precompiler 300, and 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 in the compiler or as an independent functional module outside the compiler.

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

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

[0266] Exemplarily, the abnormal indication information may indicate relevant information of the risk operation involved in risk node #2. For example, the relevant information of 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, etc.

[0267] The above is only an example, and the embodiment of the present application does not limit the representation form of the abnormal indication information.

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

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

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

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

[0272] Uncertainty vulnerabilities usually have no safe operations that can be used to replace them, and can only be solved by avoiding risky operations related to uncertainty vulnerabilities. In the solution of the embodiment of the present application, when risky operations related to uncertainty vulnerabilities are identified, that is, when uncertainty vulnerabilities are identified, an error can be reported to remind the user to handle it.

[0273] In addition, in the solution of the embodiment of the present application, if an uncertainty vulnerability is identified, the compilation or pre-compilation of the source contract can be refused. In this way, the contract cannot be deployed and run, avoiding uncertainty vulnerabilities from the source, thereby helping to improve the security of the contract.

[0274] Furthermore, a mechanism for enabling or disabling the uncertainty vulnerability prevention function may be provided to the user. The uncertainty vulnerability prevention function is provided by strategy #2, and enabling or disabling the uncertainty vulnerability prevention function is the enabling or disabling of strategy #2.

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

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

[0277] Exemplarily, the user's operation on the selection control is obtained to change the state of the uncertainty vulnerability prevention function. The state of the uncertainty vulnerability prevention function includes an enabled state or a disabled state. 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 current uncertainty vulnerability prevention function is in a disabled state, the uncertainty vulnerability prevention function is enabled, that is, strategy #2 is executed. After obtaining the user's click operation on the selection control, if the current uncertainty vulnerability prevention function is in an enabled state, the uncertainty vulnerability prevention function is disabled.

[0278] 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 vulnerabilities through controls can also be adopted in other ways, and the embodiment of the present application does not limit this.

[0279] In another possible implementation, a mechanism for enabling or disabling the uncertainty vulnerability prevention function may be provided for each operation.

[0280] In other words, whether or not to execute Strategy #2 for each operation is independent of each other, allowing users to partially enable or disable the uncertainty vulnerability prevention function for each operation. For example, if the user disables the uncertainty vulnerability prevention function for a certain operation, that is, partially disables Strategy #2, no reminder information will be output for this operation, and Strategy #2 will still be executed for other operations that have enabled the uncertainty vulnerability prevention function.

[0281] For example, an uncertainty annotation may be provided, and the uncertainty annotation is used 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 may be set to an enabled state. The user may add an uncertainty annotation to the operation that needs to disable policy #2 to partially disable policy #2.

[0282] Disabling strategy #2 for a certain operation can be understood as not throwing an exception indication for the operation. For example, if an operation has an uncertainty annotation, strategy #2 is disabled for the operation, and no error is triggered even if the operation belongs to the risk set.

[0283] For example, the uncertainty annotation can be annotated with a @NotDet rule.

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

[0285] Alternatively, step 530 may include: the risk operation corresponding to risk node #2 belongs to the risk set, and when 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.

[0286] 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. After disabling the uncertainty vulnerability prevention function, the language expression ability can be improved in some cases.

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

[0288] Example #1:

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

[0290] That is, the risk operations related to the 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.

[0291] In other words, if a risk operation will lead to uncertainty under any circumstances, then this risk operation is a risk operation that will lead to uncertainty vulnerabilities in any scenario. If a risk operation will lead to uncertainty only under some conditions, but not under other conditions, then this risk operation is a risk operation that will lead to uncertainty vulnerabilities in some scenarios.

[0292] The uncertainty condition corresponding to the risk operation can be used to determine whether the risk operation will lead to uncertainty vulnerabilities. For example, if a risk operation meets the uncertainty condition corresponding to the risk operation, then the risk operation will lead to uncertainty vulnerabilities. Otherwise, it will not lead to uncertainty vulnerabilities, for example, as shown in Table 5. The operations in the gray list library are risk operations that will lead to uncertainty vulnerabilities in some scenarios.

[0293] In this case, risk node #2 belongs to the risk set, that is, risk node #2 can be the node corresponding to the risk operation that will cause uncertainty under any circumstances, or risk node #2 can be the node corresponding to the risk operation that will cause uncertainty under certain conditions. If risk node #2 exists in the risk nodes, it means that there are risk operations that will cause uncertainty vulnerabilities under any circumstances or risk operations that will cause uncertainty vulnerabilities under certain conditions in the source contract, and the vulnerability prevention module can report an error.

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

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

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

[0297] Example #2:

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

[0299] In this case, risk node #2 belongs to the risk set, that is, risk node #2 is the node corresponding to the risk operation that will cause uncertainty in any case. If there is risk node #2 in the risk node, it means that there is a risk operation in the source contract that will cause uncertainty vulnerabilities in any case, and the vulnerability prevention module can report an error.

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

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

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

[0303] Example #3:

[0304] In yet 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.

[0305] The elements in the first risk set will lead to uncertainty vulnerabilities in any scenario. The elements in the second risk set will lead to uncertainty vulnerabilities in some scenarios.

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

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

[0308] Table 5

[0309]

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

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

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

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

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

[0315] The execution order of the judgment of the above conditions can be set as needed. For example, first determine whether the risk operation corresponding to risk node #2 belongs to the blacklist library. If the risk operation corresponding to risk node #2 belongs to the blacklist library, 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 blacklist library.

[0316] The above is only an example and does not constitute a limitation on the solutions of the embodiments of the present application.

[0317] 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 satisfies the uncertainty condition corresponding to the risk operation, an exception indication information is thrown.

[0318] For example, risk node #2 involves risk operation #2 (an example of the second risk operation). If risk operation #2 belongs to the gray list library and risk operation #2 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 vulnerabilities.

[0319] When the risk operation corresponding to a risk node belongs to the gray list library, it can be determined whether the risk operation corresponding to the risk node meets the corresponding uncertainty condition. If it does, the risk operation corresponding to the risk node will cause uncertainty, in which case, an abnormal indication information can be thrown. Otherwise, the risk operation corresponding to the risk node will not cause uncertainty, in which case, there is no need to throw an abnormal indication information.

[0320] In this way, the accuracy of the uncertain vulnerability judgment results can be further improved, which is convenient for users to handle later and is conducive to improving user experience.

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

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

[0323] 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 is triggered and an exception indication message is thrown. Otherwise, the error reporting mechanism will not be triggered.

[0324] The execution order of the judgment of the above 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 belongs 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 belongs to the gray list library, then determine whether the risk operation corresponding to risk node #2 meets the uncertainty condition.

[0325] The above is only an example and does not constitute a limitation on the solutions of the embodiments of the present application.

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

[0327] Exemplarily, throwing the exception indication information and rejecting the compilation or pre-compilation of the source contract may be bound, that is, in the case of throwing the exception indication information, the compilation or pre-compilation of the source contract is rejected.

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

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

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

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

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

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

[0334] Add a permission detection condition to risk node #3 (an example of 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 risk node #3 is called.

[0335] Risk node #3 involves access rights.

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

[0337] When the target contract is running, it will determine whether the permission detection conditions are met, that is, verify the identity of the function caller. If it is met, that is, the identity authentication is successful, then the relevant operations corresponding to risk node #3 are allowed to be executed. If it is not met, that is, the identity authentication fails, an error is reported. Furthermore, the contract operation can be terminated when the identity authentication fails.

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

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

[0340] 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 beneficial to improving the security of contract operation and avoiding permission control loopholes.

[0341] Exemplarily, in step 530, the tree nodes of AST#4 may be traversed, and strategies #1, #2, and #3 may be executed to obtain AST#5. AST#5 may be regarded as an AST with a vulnerability defense mechanism added. If only strategy #2 is executed, AST#5 and AST#4 may be syntax trees of the same structure.

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

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

[0344] The method 500 and the method 200 may be used in combination.

[0345] Exemplarily, method 500 may be performed between step 240 and step 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#2 in step 250 is replaced by AST#5, that is, in step 250, a target contract is generated based on AST#5.

[0346] In the scheme of the embodiment of the present application, corresponding preventive measures are set for various common vulnerabilities in the field of smart contracts, which greatly improves the security of smart contracts. At the same time, these measures can reduce the processing that users need to perform at the code level, which is conducive to simplifying the coding process, reducing the cost of use, and improving development efficiency. Moreover, this can also reduce 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 that users need to perform at the code level, which can further reduce the learning threshold for contract development, that is, reduce the entry cost.

[0347] Exemplarily, using safe operations to replace some risky operations is helpful to 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, thereby reducing or avoiding the above-mentioned 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, errors 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 identity of the visitor can be verified at runtime, which is helpful to avoid permission control vulnerabilities.

[0348] Most vulnerabilities in smart contracts come from the language level. The embodiments of the present application optimize the processing of the programming language of smart contracts. In the scheme of the embodiments of the present application, vulnerability prevention measures can be embedded in the language, for example, embedded in the compiler, or embedded in the precompiler, which is conducive to avoiding vulnerabilities from the source, thereby improving the security of the programming language, or in other words, improving the security of smart contracts.

[0349] Smart contracts face a variety of migration requirements, such as the migration requirements from public environments to private environments, and the migration requirements from unlicensed chains to licensed chains. However, there are large differences in the underlying architecture of the operating environments of various contracts (for example, various blockchain platforms) and the programming languages ​​supported by smart contracts, which makes it difficult for smart contracts to be effectively migrated between various operating environments, that is, the portability of smart contracts is low. This results in the need to repeatedly implement related smart contracts when migrating applications, and the migration cost is high. The portability of smart contracts means that the written smart contracts can run in multiple operating environments.

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

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

[0352] Figure 6 Another method for processing a smart contract provided by an embodiment of the present application is shown. Method 600 can also be called a method for migrating a smart contract, or a method for converting a programming language. In method 600, the migration of the platform is achieved by means of concept mapping.

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

[0354] The platform migration device may also be deployed in other devices as a functional module of other devices. In this case, the platform migration device may also be referred to as a platform migration module.

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

[0356] 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 in the same module.

[0357] like Figure 6 As shown, method 600 may include the following steps.

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

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

[0360] Exemplarily, the AST#6 may be parsed by a compiler. For example, if the programming language of the source contract is Java, the compiler may be a Java compiler. For another example, if the programming language of the source contract is Solidity, the compiler may be a Solidity compiler.

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

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

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

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

[0365] 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). The initial tree node #S1 corresponds to the initial syntax element #1 (an example of the first initial syntax element) in the source language, and the target tree node #T1 corresponds to the 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.

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

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

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

[0369] Optionally, step 620 may include: replacing the initial tree node #S1 with the target tree node #T1 according to a 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.

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

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

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

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

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

[0375] Table 6

[0376]

[0377]

[0378] 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. An exemplary description is given below in conjunction with Table 6.

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

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

[0381] 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 included 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.

[0382] For grammatical concepts that exist in the source language, if they do not exist in the target language, they are represented as expansion and replacement relationships in the mapping relationship.

[0383] 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, that is, the grammatical concept #A does not exist in the target language.

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

[0385] For example, in JSmarter, "json2Obj()" is used to convert a Json string into an object, and there is no predefined function in Solidity that implements this syntax function. As shown in Table 6, "json2Obj()" corresponds to a code segment that implements the syntax function of "json2Obj()" based on the Solidity language. The initial syntax element #1 may be json2Obj(), the initial tree node #S1 may be a node corresponding to json2Obj(), and the target tree node #T1 corresponds to the corresponding code segment in Table 6, i.e., the target syntax element #1.

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

[0387] Exemplarily, for grammatical elements with the same grammatical function but different grammatical structures in the source language and the target language, 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, mapping can be performed in a supplementary mapping manner. The target grammatical element #1 and the initial grammatical element #1 implement the same grammatical function, and the grammatical concept used by the target grammatical element #1 does not exist in the initial grammatical element #1. In this case, mapping the initial tree node #S1 to the target tree node #T1 can be performed by supplementing the node corresponding to the grammatical concept used by the target grammatical element #1 of the target language in the initial tree node #S1.

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

[0389] There may be differences in identity information and permission control between different platforms. For example, the consortium chain of the blockchain is divided into different organizations, and each account belongs to a different organization. Different organizations have different permissions. The public chain only has the concept of accounts, not the concept of organizations. If the source contract is oriented to the consortium chain, when it needs to be transplanted to the public chain, the differences in identity information and permission control between the two platforms need to be processed. The differences in identity information and permission control can be achieved through platform-level mapping. Specifically, it can be achieved through step 630 and / or step 640.

[0390] 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). Among them, 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.

[0391] Exemplarily, platform #2 can be a blockchain platform that supports the source language. Alternatively, in the case where 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.

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

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

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

[0395] Take platform #2 as a consortium chain platform and platform #3 as a public chain platform as an example. There is no information about the organization in the public chain platform. When migrating from the consortium chain platform to the public chain platform, operations related to the organization need to be removed. In the mapping relationship between multiple candidate initial operations and multiple candidate replacement operations, the multiple candidate initial operations may include operations on the organization, and the multiple candidate replacement operations may include operations on the public ledger. The mapping relationship between multiple candidate initial operations and multiple candidate replacement operations can be used to indicate the mapping relationship between operations on the organization and operations on the public ledger.

[0396] For example, platform #2 may involve operations related to channels, and the operations related to channels belong to operations on organizations. The operations related to channels may correspond to operations on public ledgers. In other words, the operations related to channels belong to multiple candidate initial operations, and the operations on public ledgers belong to the multiple candidate replacement operations. In the mapping relationship between the multiple candidate initial operations and the multiple candidate replacement operations, the operations related to channels correspond to operations on public ledgers.

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

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

[0399] 640, embed the 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 platform #2.

[0400] The permission control code may be a sample code containing permission control logic. The permission control code may also be referred to as a permission control sample code. The permission control sample code may be pre-built based on the permission relationship between the various identity information in platform #2. Taking platform #2 as an alliance chain platform as an example, sample code containing permission control logic and its instructions for use may be pre-built based on the permission relationship between various organizations.

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

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

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

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

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

[0406] Step 630 and step 640 may be viewed as platform-level mapping.

[0407] 650, fill AST#7 into the target structure, the target structure is defined by the target contract template to generate the target contract.

[0408] AST#7 may 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 .

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

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

[0411] Figure 7 A schematic diagram showing the structure of a target contract template using the Solidity language.

[0412] 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, throwing exception, return statement and other basic syntax and processing logic.

[0413] 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 a target contract.

[0414] Exemplarily, the tree nodes in AST#7 are traversed to extract structural features. Taking the function call node as an example, the structural features may include: the function name of the function call node, the function caller or the function parameter value, etc. The structural features are filled into the target structure indicated by the target contract template to generate the target contract.

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

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

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

[0418] In addition, in the embodiment of the present application, the permission control code is injected into the target contract, and the permission control code is used to indicate the permission relationship in platform #2, so as to realize the processing of the difference in permission control between platform #2 and platform #3. In this way, the user can modify and call the permission control code as needed, thereby realizing the permission control in the smart contract, which is conducive to reducing the migration cost.

[0419] In the embodiment of the present application, method 200, method 500 and method 600 can be used in combination. For example, any two of the methods 200, method 500 and method 600 in the embodiment of the present application can be used in combination. For another example, in the embodiment of the present application, the three schemes of method 200, method 500 and method 600 can be used in combination.

[0420] When used in combination with other solutions, method 600 can be used as a specific implementation of the language conversion function. Further, 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.

[0421] 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, and if the user enables the language conversion function, method 600 is executed.

[0422] When used in combination with other solutions, method 500 can be used as a specific implementation of the vulnerability prevention function. Further, the vulnerability prevention function can be used as an optional function, that is, a mechanism for enabling or disabling the vulnerability prevention function is provided to the user.

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

[0424] The combination of method 200 and method 500 can be referred to in the previous text and will not be described in detail here.

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

[0426] Exemplarily, 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, method 200 and method 600 are executed to output a character stream of the target language.

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

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

[0429] Exemplarily, the language conversion function may be an optional function in a compiler.

[0430] Exemplarily, the vulnerability prevention function may be an optional function in the compiler.

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

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

[0433] Exemplarily, the language conversion function may be an optional function of the precompiler.

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

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

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

[0437] Figure 8 A schematic diagram showing the architecture of a JSmarter precompiler.

[0438] like Figure 8 As shown, the precompiler of JSmarter may include a syntax parsing module 310 , a vulnerability prevention module 320 and a platform transplantation module 330 .

[0439] The syntax parsing module 310 can act on the syntax parsing stage. The vulnerability prevention module 320 can act on the semantic analysis stage. The platform transplantation module 330 can act on the code generation stage. Figure 3 The code generation module 330 can be the same module.

[0440] Figure 8The precompiler shown can preprocess the extended syntax, which is helpful to ensure that the extended syntax can pass compilation. At the same time, a vulnerability prevention mechanism and a language conversion mechanism are introduced to process the contract code, thereby improving the security and portability of the contract.

[0441] For example, Figure 8 As shown, the input of the syntax parsing module 310 can be the source contract developed using JSmarter, i.e., the JSmarter source code, and the output can be the parsed AST (i.e., 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 (i.e., AST#2) output by the syntax parsing module 310, and the output can be the AST (i.e., AST#5) to which a vulnerability defense mechanism is added. The AST to which a vulnerability defense mechanism is added can be called the checked AST. The platform transplantation 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 transplantation 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.

[0442] In the scheme 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.

[0443] Fig. 9 A schematic diagram showing the workflow of the JSmarter precompiler. Fig. 9 The scheme shown can be regarded as a specific implementation method of the combination of method 200, method 500 and method 600, and does not constitute a limitation on the scheme of the embodiment of the present application.

[0444] For example, Fig. 9 As shown in the figure, 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 Fig. 9 The JSmarter source code in the source code is processed to obtain the character stream of the target language, i.e. the target contract. The JSmarter precompiler generally follows the principle of Java compilation, including three stages: syntax parsing, semantic analysis and code generation. Figure 8 The three modules shown illustrate the various stages.

[0445] Fig.10 A schematic diagram showing the workflow of the syntax parsing module 310 is shown.

[0446] like Fig.10 As shown, 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.

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

[0448] 911, token recognition.

[0449] Identify the token of the target keyword.

[0450] 912, annotation generation.

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

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

[0453] 921, annotation processing.

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

[0455] 922,Syntax interface mapping.

[0456] 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 HF platform as an example, the syntax interface is specifically implemented based on the underlying call API of the HF platform. For example, the syntax interface defined in the precompiler and its corresponding extended syntax can be referred to in Table 3.

[0457] In addition, as shown in Table 3, if the detected tree node is modified with a Java annotation, it can be mapped to a syntax interface defined in the precompiler that matches it. 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 syntax interface defined in the precompiler that matches it.

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

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

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

[0461] Fig.11 A schematic diagram showing the workflow of the vulnerability prevention module 320 is shown.

[0462] like Fig.11 As shown, the AST output by the syntax parsing module 310 is input into the vulnerability prevention module 320, and the vulnerability prevention module 320 executes steps 1010 and 1020 to output the checked AST.

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

[0464] 1011. If the operation involved in the tree node exists in the security 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 security operation library.

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

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

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

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

[0469] 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 the annotation, it can be considered that the user approves and allows the uncertainty to be retained here, and the precompiler does not process it. If the tree node does not have the annotation, the compilation error mechanism is triggered, that is, the contract code is rejected from being compiled, and an exception indication message is thrown to prompt the user to handle the vulnerability.

[0470] 1013. If the operation involved in the tree node exists in the gray list 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 considered that the user approves 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 handle the vulnerability.

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

[0472] 1014. If the tree node involves access permission control, a check node corresponding to the check statement for the function caller is added before the node corresponding to the function body.

[0473] That is, a verification statement for the function caller is added at the front of the function body, and the verification statement is used as a runtime condition to implement runtime detection. Specifically, the contract code performs additional verification on the identity of the function caller during actual runtime. If the identity verification fails, the runtime error mechanism is triggered, that is, the contract operation is terminated and an exception is thrown.

[0474] 1020, after all tree nodes in the AST output by the syntax parsing module 310 are traversed, an AST with a vulnerability prevention mechanism added is output (an example of AST#5).

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

[0476] Fig.12 FIG. 3 is a schematic diagram showing the workflow of the platform transplantation module 330. Fig.12 In the scheme shown, a concept mapping strategy is designed based on the differences between the source language and the target language in the blockchain platform mechanism and contract syntax, and a concept mapping table is constructed for rapid language conversion.

[0477] like Fig.12 As shown, 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 of the target language. Exemplarily, 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 of 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 of a language other than the Java language.

[0478] 1110, obtain a concept mapping table.

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

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

[0481] like Fig. 9 As shown, after obtaining the concept mapping table, the benchmark grammar can be concept mapped, and feature extraction can be performed on the AST processed by the concept mapping to generate a target contract.

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

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

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

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

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

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

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

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

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

[0491] For example, identification Fig.12 The four core concepts of extended keywords, data types, built-in variables and built-in functions are mapped to the core concepts in the target language.

[0492] It should be understood that Fig.12 This is just 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 found in the previous article, and will not be repeated here.

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

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

[0495] 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 authority 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%.

[0496] Fig.13 It is a schematic block diagram of the operating environment of the smart contract of an embodiment of the present application.

[0497] like Fig.13 As shown, 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 the Java language or a character stream of a language other than the 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.

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

[0499] Combine the following Figures 14 to 17 The device of the embodiment of the present application is described. It should be understood that the device described below can execute the method of the embodiment of the present application, and in order to avoid unnecessary repetition, repeated descriptions are appropriately omitted when introducing the device of the embodiment of the present application.

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

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

[0502] In a possible implementation, the processing device 2000 may be used to execute Figure 5 Further, the processing device 2000 can also be used to perform Figure 2 and / or Figure 6 The method shown.

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

[0504] The first processing module 2020 is used to:

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

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

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

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

[0509] Optionally, the processing device 2000 is applied in a compiler.

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

[0511] Optionally, 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.

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

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

[0514] Optionally, the first processing module 2020 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 multiple candidate risk operations, and the first safety operation belongs to multiple candidate safety operations.

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

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

[0517] Optionally, the processing device 2000 further includes a second processing module, which is used 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.

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

[0519] Optionally, the second processing module is specifically used to: replace the second initial node with the second target node according to a 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.

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

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

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

[0523] Optionally, the processing device 2000 also includes a second acquisition module (not shown in the figure), which is used to obtain the tag sequence of the source contract; a third processing module (not shown in the figure), which is used to: convert 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, the target keyword belongs to the keyword in the extended grammar; generate a third syntax tree based on the processed tag sequence; replace the third initial node in the third syntax tree with the grammar interface corresponding to the third initial node to obtain the first syntax tree, 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.

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

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

[0526] As an example of a software functional unit, the first processing module 2020 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned 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 can be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code can be distributed in the same availability zone (AZ) or in different AZs, each AZ including a data center or multiple data centers with similar geographical locations. Among them, usually a region can include multiple AZs.

[0527] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0528] As an example of a hardware functional unit, the first processing module 2020 may include at least one computing device, such as a server, etc. Alternatively, the first processing module 2020 may also be a device 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.

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

[0530] 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, the first acquisition module 2010 can be used to execute any step in the processing method of the smart contract, and the steps that each module is responsible for implementing can be specified as needed. The full functions of the processing device 2000 are realized by implementing different steps in the processing method of the smart contract through each module.

[0531] The present application also provides a computing device 1000. Fig.15 As shown, computing device 1000 includes: bus 1002, processor 1004, memory 1006 and communication interface 1008. Processor 1004, memory 1006 and communication interface 1008 communicate through bus 1002. Computing device 1000 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in computing device 1000.

[0532] The bus 1002 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 9 The bus 1002 may include a path for transmitting information between various components of the computing device 1000 (eg, the memory 1006, the processor 1004, and the communication interface 1008).

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

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

[0535] The memory 1006 stores executable program codes, and the processor 1004 executes the executable program codes to respectively implement the functions of the first acquisition module 2010 and the first processing module 2020, thereby implementing the processing method of the smart contract. That is, the memory 1006 stores instructions for executing the processing method of the smart contract.

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

[0537] The embodiment of the present application also provides 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 smart phone.

[0538] like Fig.16 As shown, 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 of the processing method for executing the smart contract.

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

[0540] It should be noted that the memory 1006 in different computing devices 1000 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the processing device of the smart contract. That is, 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.

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

[0542] Fig.17 A possible implementation is shown. Fig.17 As shown, two computing devices 1000A and 1000B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 1006 in the computing device 1000A stores instructions for executing the functions of the first acquisition module 2010. At the same time, the memory 1006 in the computing device 1000B stores instructions for executing the functions of the first processing module 2020.

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

[0544] It should be understood that Fig.17 The functions of the computing device 1000A shown in FIG. 1000A 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.

[0545] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be a software or program product including 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, the at least one computing device executes a processing method for a smart contract.

[0546] The embodiment of 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 containing 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 hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute a processing method for a smart contract.

[0547] Those of ordinary skill 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 to be beyond the scope of this application.

[0548] Those skilled in the art can 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.

[0549] In the several embodiments provided in the present 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 only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, 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.

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

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

[0552] 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 can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the processing method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0553] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope 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 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.

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 as claimed in 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