Method and system for supporting smart contracts in a blockchain network

Abstract

A computer-implemented method for supporting smart contracts in a blockchain network includes converting source code of the smart contract into an abstract syntax tree model, generating a code property graph based on the abstract syntax tree model, performing an augmentation process to augment the code property graph with information inferable from the abstract syntax tree model, performing a vulnerability detection process in which the code property graph is examined for one or more predefined vulnerability patterns to find one or more predefined vulnerabilities, and performing a vulnerability patching process in which one or more patches are applied to fix vulnerabilities found in the vulnerability detection process and the patches are inserted into the code property graph to generate a patched code property graph. Moreover, a corresponding computer system for supporting smart contracts in a blockchain network is disclosed.

Description

Technical Field

[0001] The present invention relates to a computer-implemented method for supporting smart contracts in a blockchain network.

[0002] Furthermore, the present invention relates to a computer system for supporting smart contracts in a blockchain network.

Background Art

[0003] Since the inception and implementation of Bitcoin in 2009, cryptocurrencies have achieved wide acceptance. Bitcoin was initially designed as a peer-to-peer payment infrastructure using a concept called blockchain as an enabling technology. A blockchain is an additional dedicated distributed data structure that enables parties who do not trust each other to participate in transactions with each other by using cryptographically secure signatures. Data can be stored in the blockchain in a cryptographically secure and distributed manner, and participating nodes determine to add data to the blockchain according to a consensus protocol such as proof of work or proof of stake for adding data to the blockchain.

[0004] The new market brought about by the emergence of blockchain technology has grown to consist of over 2,500 cryptocurrencies today. These so-called altcoins are implemented using alternative blockchains to the Bitcoin infrastructure. Some of these altcoins also provide, in addition to a payment infrastructure, a means, usually referred to as smart contracts, for executing programs on the blockchain. One of the most prominent blockchain networks featuring smart contracts is the Ethereum blockchain. In the Ethereum blockchain, a smart contract is a program in the form of special bytecode that is always triggered when a transaction is sent to the contract's address. The smart contract is then executed in the Ethereum Virtual Machine (EVM) by the same nodes that verify and add the transaction to the blockchain. To date, nearly two million smart contracts have been deployed on the Ethereum blockchain.

[0005] Ethereum smart contracts are Turing-complete programs that can implement autonomous agents on the blockchain, as they can manage their own Ether cryptocurrency and trigger further actions such as transferring Ether to another account or generating transactions to other smart contracts, for example, to call other smart contracts. However, like conventional software, smart contracts are vulnerable to programming errors. Additionally, when the nature of blockchain transactions is combined with incorrect assumptions about the smart contract programming model, semantic gaps occur. One such incorrect assumption was that transactions were executed in sequence, when in fact transactions can initiate nested transactions. This ultimately results in many bugs in smart contracts. Since smart contracts sometimes manage significant amounts of cryptocurrency, they are valuable targets for attackers who may attempt to exploit security vulnerabilities for direct financial gain. One of the first well-known incidents related to smart contract development was the "TheDAO" hack, in which Ether suffered damages equivalent to approximately $50 million at the time of the incident (see Rob Price's non-patent literature "Digital currency Ethereum is cratering because of a $50 million hack" in June 2016, available at https: / / www.businessinsider.com / dao-hacked-ethereum-crashing-in-value-tens-of-millions-allegedly-stolen-2016-6). In this case, the attacker exploited a so-called reentrancy vulnerability. Since smart contracts can send transactions to other smart contracts, this means that transactions can generate nested transactions. In the case of the reentrancy vulnerability, this fact is exploited to disable certain security-related checks in the code of the victim smart contract.Therefore, in the case of the "The DAO" hack, the attacker was able to repeatedly withdraw a certain amount of Ether by exploiting the reentrancy vulnerability.

[0006] Apart from reentrancy attacks, to name two or three examples, there are other problems such as integer bugs like integer overflow and integer underflow, and access control and input validation bugs. In recent years, several efforts have been made to research new methods for preventing security vulnerabilities in smart contracts. These efforts follow several techniques ranging from symbolic execution to formal verification and static analysis. In this regard, the following non-patent documents are exemplarily referred to. - Christof Ferreira Torres, Julian Schutte et al., "Osiris: Hunting for Integer Bugs in Ethereum Smart Contracts", The 34th Annual Computer Security Applications Conference (ACSAC18), San Juan, Puerto Rico, USA, December 3 - 7, 2018, 2018, URL: http: / / orbilu.uni.lu / handle / 10993 / 36757. - Loi Luu et al., "Making Smart Contracts Smarter", Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS'16, Vienna, Austria: ACM, 2016, pp. 254 - 269. - Mark Mossberg et al., "Manticore: A User-Friendly Symbolic Execution Framework for Binaries and Smart Contracts", (July 2019), arXiv: 1907.03890[cs.SE]. - Sukrit Kalra et al., "ZEUS: Analyzing Safety of Smart Contracts", Proceedings of the 2018 Network and Distributed System Security Symposium, San Diego, California, Internet Society, 2018. - Petar Tsankov et al., "Security: Practical security analysis of smart contracts", Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, ACM, 2018, pp. 67 - 82.

[0007] Most of this work focuses on static analysis before deploying smart contracts. Static analysis and verification are most useful to smart contract developers, but some dynamic analysis techniques similar to the exploit mitigation mechanisms in traditional software that identify and prevent vulnerabilities during the execution of smart contracts have emerged. For example, Sereum has been proposed as a system that not only detects reentrancy attacks but also mitigates reentrancy attacks by a locking mechanism enforced at runtime. In Sereum, all participating nodes must perform the analysis, and flagged transactions are not included in the blockchain. Similarly, in the non-patent literature by Torres et al., "ZEGIS: Smart Shielding of Smart Contracts", Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, CCS 2019, London, UK, November 11 - 15, 2019, edited by Lorenzo Cavallaro et al., ACM, 2019, pages 2589 - 2591, DOI: 10.1145 / 3319535.3363263, URL: https: / / doi.org / 10.1145 / 3319535.3363263, solutions are proposed where vulnerability patterns are managed within the blockchain and their approval is determined by voting by network participants. However, such dynamic analysis techniques do not reflect the security policies enforced by the dynamic analysis system in either the source code or the contract bytecode, increasing the semantic gap and thus have not been effectively integrated into a wider blockchain ecosystem. Since the Ethereum blockchain prevents any changes to the code of deployed smart contracts by design, vulnerability detection remains a particularly important topic as it is. Therefore, even if a vulnerability is discovered in a smart contract, it is not easy to upgrade the smart contract.However, the contract has certain code patterns and functions of the Ethereum platform that enable it to emulate the functions necessary to make the contract upgradeable. However, it is the responsibility of the contract developer to accurately apply this pattern as needed. Therefore, given the risk of any bugs in the smart contract, it is important to strengthen the code of the smart contract.

Prior Art Documents

Non-Patent Documents

[0008]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

[0009] Therefore, from the above perspective, the object of the present invention is to improve and further develop the method and computer system of the type described at first for supporting smart contracts in a blockchain network in such a way as to efficiently strengthen smart contracts, particularly to improve possible vulnerabilities. [Means for Solving the Problems]

[0010] According to the present invention, the foregoing object is achieved by a computer-implemented method for supporting a smart contract in a blockchain network, the method comprising: converting the source code of the smart contract into an abstract syntax tree model; generating a code property graph based on the abstract syntax tree model; performing an expansion process of expanding the code property graph using information inferable from the abstract syntax tree model; performing a vulnerability detection process, wherein the code property graph is inspected to determine whether there are one or more predetermined vulnerability patterns for finding one or more predetermined vulnerabilities; performing a vulnerability patching process, wherein one or more patches are applied to correct the vulnerabilities found in the vulnerability detection process, and the patches are inserted into the code property graph such that a patched code property graph is generated; and

[0011] Furthermore, the foregoing object is achieved by a computer system for supporting a smart contract in a blockchain network, the storage device and the one or more processors comprised by the system being configured to perform the method, alone or in combination, the method comprising: converting the source code of the smart contract into an abstract syntax tree model; generating a code property graph based on the abstract syntax tree model; performing an expansion process of expanding the code property graph using information inferable from the abstract syntax tree model; performing a vulnerability detection process, wherein the code property graph is inspected to determine whether there are one or more predetermined vulnerability patterns for finding one or more predetermined vulnerabilities; Executing a vulnerability patching process, in which one or more patches are applied to correct the vulnerabilities found in the vulnerability detection process, and patches are inserted into the code property graph such that a code property graph with the applied patches is generated, and including.

[0012] In most cases, runtime or compiler-dependent policies are used to implement a defense mechanism for original C / C++ software. However, according to the present invention, in the situation of strengthening smart contracts, it has been first recognized that developers of smart contracts may wish to consider semantic changes to their smart contracts. Embodiments of the present invention do not enforce policies that strengthen by changing the meaning of the runtime environment or bytecode measurement, but rather advocate rewriting the source code as the most straightforward way to automatically strengthen smart contracts in an efficient manner. Rewriting the source code may maintain the inspectability of the smart contract and allow the developers in charge of the smart contract to continue to approve the changes and the implications of the changes. For this purpose, according to the present invention, the source code of the smart contract is translated / transformed into an abstract syntax tree model, particularly by a compiler entity. Then, the abstract syntax tree model is converted into a code property graph, which may be used to analyze the smart contract to be inspected. Moreover, an expansion process is executed to expand the code property graph using information inferable from / by the abstract syntax tree model. Then, by executing a vulnerability detection process, the code property graph is inspected to see if there are one or more predetermined vulnerability patterns in order to find one or more potential predetermined vulnerabilities. When a predetermined vulnerability pattern is found, a vulnerability patching process is executed, and one or more predetermined patches are applied to correct one or more vulnerabilities found in the vulnerability detection process. Patches are directly inserted into the code property graph such that a code property graph with the applied patches is generated.

[0013] Accordingly, the present invention provides a method and system for supporting smart contracts in a blockchain network, where the smart contracts are efficiently strengthened so as to be able to improve and eliminate potential vulnerabilities in the contracts.

[0014] According to an embodiment of the present invention, the blockchain network may be a distributed network having nodes, and by means of the blockchain, each node can participate in transactions with each other by using cryptographically secure signatures. Accordingly, the blockchain may also be an additional dedicated distributed data structure that enables parties who do not trust each other to participate in transactions with each other by using cryptographically secure signatures. The data may be distributed and stored on the blockchain in a cryptographically secure manner, and the participating nodes determine the data to be added according to a consensus protocol such as proof of work or proof of stake in order to add the data to the blockchain.

[0015] According to an embodiment of the present invention, when a transaction is sent to the address of a smart contract, the smart contract may always be triggered. The smart contract may be executed in a virtual machine by a blockchain node that verifies and adds the transaction to the blockchain. Accordingly, the smart contract may also be a program in a special bytecode format that is always triggered when a transaction is sent to the contract address.

[0016] According to an embodiment of the present invention, the code property graph may include an expression combining a data flow graph, a control flow graph, and / or a dominator tree. Therefore, the code property graph may merge three graph expressions of the code into a joint data structure. Thus, the code property graph (CPG) is a program expression that unifies various expectations on a program that may generally be realized by static analysis. The main advantage of the concept of the code property graph is that the planned graph is not language-dependent. As a result, it is possible to write graph analysis without being specific to a particular language, enabling the reuse of many types of analysis.

[0017] According to an embodiment of the present invention, the step of performing the expansion process may include call analysis. The call analysis may include a step of repeating over all function call expressions in the code property graph and a step of assigning a call label to each external function call. Therefore, it can be efficiently applied in the vulnerability detection process and appropriate information for use can be collected.

[0018] According to an embodiment of the present invention, the step of performing the expansion process may include contains-call-analysis. The contains-call-analysis may include a step of analyzing a sub-expression of all statements in the code property graph to find function calls and a step of assigning a call label to each statement having a function call. Therefore, it can be efficiently applied in the vulnerability detection process and appropriate information for use can be collected.

[0019] According to an embodiment of the present invention, the step of performing the expansion process may include write-state-analysis. The write-state-analysis may include a step of collecting all statements that change the state variables of the smart contract and the collected statements and those Surround It may include the step of assigning writes - state - label to a function. The write - state - analysis includes the step of collecting all internal function calls that call functions for updating / writing state variables, and the collected internal function calls and those Surround It may further include the step of assigning writes - state - label to a function. Thus, it can be efficiently applied in the vulnerability detection process and collect appropriate information for use.

[0020] According to an embodiment of the present invention, a vulnerability pattern may be associated with a predetermined vulnerability. The predetermined vulnerability may include re - entrant property, integer overflow bug and / or integer underflow bug. Thus, vulnerability patterns for detecting important potential vulnerabilities in smart contracts are taken into account.

[0021] According to an embodiment of the present invention, the vulnerability pattern may be represented in the form of a CPG sub - graph. Moreover, the step of executing the vulnerability detection process may include the step of searching for a CPG sub - graph inside the code property graph of the smart contract. Thus, the concept of code property graph (CPG) can be introduced, and it becomes possible to formulate vulnerability as the search for a specific sub - graph representing vulnerability. Therefore, efficient vulnerability detection is provided. Once the process of expanding the code property graph is completed, the inspection of vulnerability patterns may be executed in the vulnerability detection process. These vulnerability patterns may be represented in the form of various sub - graphs of the code property graph. The existence of a specific sub - graph in the code property graph indicates that the smart contract is vulnerable to the related vulnerability. Once all patterns related to the vulnerability are found, the vulnerability discovery (i.e., the vulnerability detection process) can be terminated and the vulnerability patching process can be started.

[0022] According to an embodiment of the present invention, the step of executing the vulnerability detection process is a statement s that writes the state wand Surround it The method may include querying a code property graph for the function f. Then, considering the control flow of the function f, in the code property graph, an external function call c e from s w to c e that transiently leads may be searched for. The state variable sv handled by s w is also incorporated. If such a pattern is found, in the vulnerability detection process for all functions f belonging to the smart contract and writing to sv c the code property graph may also be queried. Thus, reentrancy vulnerabilities may be efficiently detected. For this purpose, the state variable sv, the statement s w writing to the state variable sv, the statement s w Surround the function f, and considering the control flow of f, the external function call c e from s w to c e that transiently leads, and the set of cross - functions f c writing to sv may be searched for a reentrancy vulnerability pattern.

[0023] According to an embodiment of the present invention, in the vulnerability detection process, the statement s w writing the state and Surround it the code property graph may be queried for the function f. Generation - based reentrancy detection considers, instead of an external call, a constructor call c c from s w to c cIt may be searched. Through CPG-based analysis, it becomes possible to analyze the constructor being called. In this way, this vulnerability may be reported only when the constructor contains an external call. Since reentrancy does not occur without an external call, this is effective. When the constructor calls an external function, the control property graph may be queried again for all functions that also write to sv belonging to the same contract. Therefore, it is possible to efficiently detect reentrant vulnerabilities.

[0024] According to an embodiment of the present invention, the step of executing a vulnerability patching process to apply a patch may include the step of bringing about a lock variable l for sv as a state variable in the code property graph. sv This may include an inspection of whether sv already has a lock variable. If it does not have a lock variable, a lock variable l sv is generated. The type of the lock variable l sv may depend on the type of sv itself. For example, if sv has a basic type such as uint256, then l sv will be of boolean type, but for mapping types, only the value type will be of boolean type. After l sv is found or inserted into the control property graph, an assignment statement is generated, which may set the state of l sv For that purpose, a lock statement lock_l sv may set the state value of l sv to true, and an unlock statement unlock_l sv may set this value to false. Then, the control flow of the function f is changed so that the lock statement, external call, and unlock statement are directly consecutive to each other as lock_l sv →c e →unlock_l sv After the control flow is changed, it is inspected that l sv is unlocked and l svA guard to be inserted may be generated. The generation and insertion of the guard may also occur in all other functions f that write to sv. c Accordingly, the reentrancy vulnerability may be efficiently patched.

[0025] According to embodiments of the present invention, a predetermined patch may be specially created for each individual vulnerability pattern. Accordingly, embodiments of the present invention relate to a novel approach for detecting and fixing vulnerabilities in smart contracts in an efficient manner at the source code level. Due to the concept of the Code Property Graph (CPG) introduced by embodiments of the present invention, it becomes possible to formulate vulnerabilities as the search for specific subgraphs that represent the vulnerabilities. A Code Property Graph may be introduced to automatically generate source-level patches for those vulnerabilities.

[0026] Accordingly, embodiments of the present invention may include the step of using a Code Property Graph to search for a specific subgraph in the source code in order to automatically patch vulnerabilities in a smart contract at the source code level. Embodiments of the present invention apply patches that fix all vulnerabilities during the patching process and directly insert them into the CPG. In the above case, embodiments of the present invention thoroughly examine the patched CPG to generate new source code. Subsequently, the patched smart contract may be inspected against all known transactions to ensure that the contract operates properly against benign transactions and prevents attacks.

[0027] According to embodiments of the present invention, the patched Code Property Graph is thoroughly examined to generate new source code for a smart contract that incorporates one or more applied patches.

[0028] Further features, advantages, and additional embodiments will be described and will become apparent hereinafter.

[0029] Embodiments of the present invention may provide a computer system of a hardened contract compiler (HCC) implemented as a toolchain for automatically finding and patching vulnerabilities in smart contracts. Patches are applied to the source code, maintaining the inspectability of the source code. This allows developers to verify changes introduced by HCC using the same methods as previously used, such as manual code review, formal verification, or other analysis tools. In contrast to previous static analysis tools, HCC also strives to sufficiently harden smart contracts against certain classes of bugs. In this disclosure, it is mainly focused on the automatic detection and prevention of specific vulnerabilities such as reentrant vulnerabilities and bugs in integer overflows and underflows. However, since HCC may be designed as a modular framework, it becomes possible to perform additional vulnerability detection and patching procedures with minimal effort. For this purpose, a static source code analysis technique based on a code property graph (CPG) is implemented, which enables formulating vulnerability detection as a query on a generalized graph representing the program. Smart contract developers may intend to use HCC while developing a smart contract, automatically introducing and then deploying hardening patches. However, the HCC system may also be used to facilitate the process of manually patching already deployed contracts developed as upgradeable contracts (e.g., using the ZeppelinOS framework).

[0030] Since the goal is to maintain the testability regarding contract changes, the HCC according to an embodiment of the present invention uses source code as input and issues the generated source code as output. In this way, developers can ensure that the HCC does not introduce semantic changes that affect benign transactions, and thus behavioral consistency is maintained. Some intermediate steps may be taken. First, the source code is converted into an Abstract Syntax Tree (AST). Next, the AST is converted into a Code Property Graph (CPG). The CPG is a combined representation of a Control Flow Graph (CPG), a Data Flow Graph (DFG), and a Dominator Tree (DT). This representation can be used to process some analyses such as alias analysis. Since the CPG only represents the AST at this stage, it may be extended using all the information that can be inferred by the AST to enable such analyses. Subsequently, a pattern-based approach follows to find subgraphs within the CPG that are similar to certain vulnerabilities. These subgraphs are considered as vulnerability candidates. The HCC computer system may verify the absence of a specific vulnerability prevention mechanism to determine whether this subgraph requires a patch. If the candidate is found to be an actual vulnerability, the HCC automatically applies a patch based on the found pattern. After applying a patch for each discovered vulnerability, the HCC thoroughly examines the CPG to generate new source code incorporating the patch.

[0031] Therefore, an embodiment of the present invention may provide a novel approach for detecting and fixing vulnerabilities in smart contracts at the source code level. Due to the concept of the Code Property Graph (CPG) introduced by this approach, it becomes possible to formulate vulnerabilities as the search for specific subgraphs representing vulnerabilities. Moreover, it is possible to introduce the CPG to automatically generate source-level patches for those vulnerabilities.

[0032] Embodiments of the present invention may be able to detect and patch reentrancy vulnerabilities as well as integer overflow and underflow vulnerabilities in Solidity smart contracts.

[0033] Moreover, embodiments of the present invention may provide analysis and patching tools that work across smart contract boundaries.

[0034] There are several ways to design and further develop the teachings of the present invention in an advantageous manner. For this purpose, on the one hand, the dependent claims of claim 1 are referred to, and on the other hand, the following description of further embodiments of the present invention, shown by way of example in the figures, is referred to. In connection with the description of further embodiments of the present invention with the aid of the figures, further embodiments and further developments of the present teachings are described in general.

Brief Description of the Drawings

[0035]

Figure 1

Figure 2

Modes for Carrying Out the Invention

[0036] Ethereum smart contracts suffer from several types of bugs that can lead to security vulnerabilities. The non-patent literature by Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli, "A Survey of Attacks on Ethereum Smart Contracts (SoK)", Lecture Notes in Computer Science, Abbreviation of Journal: Lecture Notes in Computer Science; Springer Berlin Heidelberg, 2017, pp. 164 - 186, DOI: 10.1007 / 978-3-662-54455-6_8, available at http: / / dx.doi.org / 10.1007 / 978-3-662-54455-6_8, presents a survey of well-known vulnerabilities and attacks. The attacks range from DoS on "KotET" contracts to the case of the Parity Multi-Sig wallet where Ether became unusable and attackers were able to steal Ether. In the infamous case of the "TheDAO" hack, attackers were able to transfer a large amount of Ether from a vulnerable contract. The attack on "TheDAO" was possible due to a bug known as the reentrancy vulnerability.

[0037] When a contract calls an external contract and this external contract calls the calling contract again within the same transaction, reentrancy occurs. Therefore, the call graph A→B→A is observed within one transaction. Reentrancy is essential for withdrawal patterns and some other program patterns, but if not implemented carefully, it can be exploited. The infamous attack on "TheDAO" demonstrated how a vulnerable implementation can lead to huge losses of Ether.

[0038] To support safe reentrancy, Solidity supports multiple high-level concepts such as transfer, send, and call for calling other contracts. All three of the above are implemented as the EVM-level CALL instruction, but differ in that the transfer and send functions provide only a limited amount of gas. By limiting the amount of gas in this way, it is possible to prevent the called contract from executing other high-gas instructions such as further call executions. However, using the wrong type of call can lead to reentrancy vulnerabilities.

[0039] Re-entrancy vulnerability occurs when a contract is unexpectedly re-entered and operates relying on some inconsistent internal states. Figure 1 is a simplified version of the "TheDAO" contract from the non-patent literature Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli, "A Survey of Attacks on Ethereum Smart Contracts (SoK)", available at http: / / dx.doi.org / 10.1007 / 978-3-662-54455-6_8, and shows the same re-entrancy vulnerability as the original "TheDAO" contract. Thus, Figure 1 is a schematic diagram showing an exemplary application scenario related to an embodiment of the present invention, and this application scenario represents an attack on the re-entrancy vulnerability of the SimpleDAO contract. The SimpleDAO contract maintains an internal state that records the amount of Ether that investors have contributed to SimpleDAO. Investors are allowed to withdraw using the withdraw function. The withdraw function must perform three steps: (1) a step of checking whether the investor is allowed to withdraw the requested amount of Ether, (2) a step of sending the amount of Ether to the investor, and (3) a step of updating the internal state to reflect that the Ether contributed by the investor to the SimpleDAO contract has decreased at this point (see Figure 1). Note that in the vulnerable SimpleDAO, step (2) is executed before updating the state in (3). This means that a malicious investor can re-enter the contract and call withdraw again, which calls the check (2) again. However, since the internal state has not been updated to reflect the withdrawal in the previous withdraw call, the attacker is allowed to pass the check and withdraw the amount again. The internal state is updated only at the end.

[0040] The attacker can repeat the reentrancy until all the Ether of the entire SimpleDAO contract has leaked out. To correct the example in Figure 1, lines 3 and 4 (see the example of the source code represented by Figure 1) are exchanged so that (3) is executed before (2). In this way, since the second call of (1) operates in a consistent state, the inspection should be useless.

[0041] The example in Figure 1 illustrates the traditional reentrancy vulnerability. However, reentrancy can follow several different vulnerability patterns as follows. - Traditional reentrancy as illustrated by the example in Figure 1. - Cross-function reentrancy where two public functions of the victim contract write separately to the same state. These functions do not need to allow traditional reentrancy when used alone. - Representative reentrancy involving three contracts, where one is used as a library by the victim contract. Even if the functions included in the library and the victim contract do not allow traditional reentrancy, the combination of those functions can enable reentrancy. This occurs when state updates and external calls occur in separate functions, and one function is from the victim contract and the representative always calls that function. Representative reentrancy can occur in two different ways as follows. (i) An external call occurs before the representative call. Since the representative call operates in the called context, it may change the state variables of the function. In this disclosure, this is referred to as "reentrancy in representative case (i)". (ii) A representative call occurs before the state update is executed. Since the representative call function may call an external function, this case can be treated the same as traditional reentrancy or cross-function reentrancy as described above. In this disclosure, this is referred to as "reentrancy in representative case (ii)". - Generation-based reentrancy that may occur when a new contract is generated before the contract executes a state update. The constructor of the newly generated contract may, in some cases, execute an external call to a malicious contract.

[0042] These vulnerability patterns have a common behavior where the state update occurs after an external call, resulting in an inconsistent state when the contract is re-entered.

[0043] This disclosure mainly focuses on reentrancy vulnerabilities, but the embodiments of the present invention are designed to be extensible to other vulnerabilities. There are many methods for detecting reentrancy vulnerabilities in smart contracts. Many of these tools rely on symbolic execution that leads to path explosion. However, since many known tools operate at the EVM level, it has been found that they have the drawback of being inaccurate. Focusing on already deployed contracts and analyzing them at the EVM level becomes inaccurate, or generally, known tools cannot detect specific reentrancy patterns.

[0044] According to embodiments of the present invention, possible fixes for reentrancy vulnerabilities can be implemented by using locks for state variables. Bytecode analysis has the drawback of lacking field sensitivity and losing reliability because there is no type information available at the EVM level. Thus, when reliability is lost, more memory locks may be associated than necessary at the EVM level. If the memory is locked more than necessary due to loss of reliability, more false detections will occur. Instead, analyzing the source code makes type information available and can prevent loss of reliability. Therefore, according to the embodiments, source code patching is targeted to provide patches with reduced overhead for patches generated at the bytecode level. Developers can further evaluate the fixes added by an embodiment of the present invention before deploying the smart contract by source code patching. So far, most solutions have been targeted at bytecode-level patching, which has a large overhead and, since it is only executed at the bytecode level, prevents developers from investigating the exact fixes introduced by the patch.

[0045] Known defense mechanisms typically utilize compiler-based measurement mechanisms to enforce their policies. Such approaches have the drawback of opacity, as the resulting binary not only reflects the source code but also enforces (compiler-dependent) policies. While this may be acceptable in many application domains, smart contract developers require greater transparency and control over the contract code. Therefore, instead of using measurement mechanisms, the source code is rewritten according to embodiments of the present invention, maintaining the inspectability and modifiability of the source code. The overhead of source code patches according to embodiments of the present invention is also typically quite small, and the code required to effectively mitigate vulnerabilities is only a few lines. Thus, by rewriting the source code, developers can verify changes according to embodiments using the same methods as before, such as manual code review, formal verification, or other analysis tools.

[0046] Embodiments of the present invention represent an enhanced contract compiler (HCC) as a toolchain that automatically finds and corrects reentrancy vulnerabilities in source code, thus maintaining inspectability, to prevent developers from deploying smart contracts vulnerable to reentrancy attacks. The present disclosure focuses primarily on the automatic detection and prevention of reentrancy vulnerabilities as well as integer overflows and underflows, but the CPG-based approach according to embodiments of the present invention allows for a design that has room for extension to other types of vulnerabilities. The primary purpose of HCC is to enable security analysis of smart contracts and assist developers in developing new secure smart contracts. However, the compilation toolchain according to embodiments can also be used to facilitate the process of manual patching of already deployed contracts.

[0047] Figure 2 shows a schematic diagram illustrating a method and system according to an embodiment of the present invention, which provides an architecture of a hardened contract compiler (HCC) with a toolchain for the automatic discovery and patching of reentrancy vulnerabilities. Rewriting of the source code of smart contracts can occur automatically in multiple processes.

[0048] As shown in Figure 2, HCC takes the source code of a smart contract as input. First, the source code has to be transformed into a model that facilitates analysis. The source code is first transformed by a compiler into an Abstract Syntax Tree (AST) model and then parsed to build the basic form of a Code Property Graph (CPG). The CPG is a representation of a program that unifies various viewpoints on the program, typically realized by static analysis. The CPG is then augmented using information that may already have been inferred from the AST. However, in this state, the CPG is essentially just another representation of the AST and may, therefore, already be extended based on itself. Thereafter, the CPG contains the basic information necessary for many analyses, such as information regarding the flow of data.

[0049] Obviously, vulnerabilities have to be found first before patching becomes possible. Once the CPG augmentation process is complete, HCC examines vulnerability patterns in the vulnerability detection process. These vulnerability patterns can be represented in the form of various subgraphs of the CPG. The presence of a particular subgraph in the CPG indicates that the contract is susceptible to the associated vulnerability. Once all patterns related to a vulnerability are found, vulnerability discovery ends and the vulnerability patching process begins.

[0050] During the vulnerability patching process, HCC directly inserts patches that fix this vulnerability into the CPG by applying them. Those patches are specially created for individual vulnerability patterns. When designing and applying patches, it is important to ensure that the modifications applied by HCC do not break any desirable functionality. For example, the business logic of the contract must remain intact.

[0051] The vulnerability patching process ends after applying the patching method to all previously found vulnerabilities. In the above case, HCC thoroughly examines the patched CPG to generate new source code. The rewritten source code can then be further considered, verified, or compiled for executability.

[0052] Basic CPG Structure: As shown in Figure 2, the basic CPG structure introduces the AST of the source code. The information in the AST contains all the high-level details of the source code, but the individual components of the AST are very granular. This means that HCC can analyze the code at the sub-expression level and also across contract boundaries.

[0053] CPG Expansion: During the CPG expansion process, HCC can perform some analyses using the information already contained in the basic CPG. During this process, the information in the CPG is extended to enable more advanced analysis. In the case of HCC, the expansion process may include multiple analyses that make the relevant information for reentrancy detection more accessible for further analysis. The expansion process serves as an advanced pre-model for vulnerability detection.

[0054] Below, the focus is mainly on reentrant vulnerabilities and bugs in integer overflows and underflows. Therefore, the CPG expansion process in HCC may include the following analyses.

[0055] Call - Analysis: When searching for re - entrant vulnerabilities, it is important to know exactly where external function calls occur in the smart contract code. To achieve this, HCC iterates through all function call expressions in the CPG and labels each call with Externalcall if it is an external call. An external call is any call that occurs when a function of another contract is directly called or when using call and delegatecall functions related to type address. The latter will be labeled not only as Externalcall but also as Delegatecall. This is sufficient to detect the conventional cross - function - type re - entrant vulnerability patterns and representative re - entrant vulnerability patterns introduced above. To detect generation - based re - entrant properties as well, HCC labels NewExpressions as Constructorcall in the CPG if the generated type is defined by another contract. Since the smart contract code needs to be available in the CPG to use NewExpression to generate a new contract, it becomes possible to analyze functions across contract boundaries.

[0056] After HCC labels all function calls, if appropriate, it labels the functions that contain them using ContainsDelegateCall, ContainsExternalCall, and ContainsConstructorCall. HCC repeats this for all function calls in the CPG and those function calls Surround Note that a function may be part of another contract. This means that the function called by Constructorcall may not be the subject of this analysis or may not contain function calls.

[0057] Contains-Call-Analysis: HCC analyzed function calls at the expression level using the aforementioned call analysis. However, most expressions are sub-expressions of statements, and although it is unnecessary, this can also be the case for function calls. Since statements are treated as the smallest (equivalent to basic blocks) control flow units of functions in the CPG, it is easier to infer function calls at the statement level during the vulnerability detection and patching process. Therefore, HCC analyzes all sub-expressions of Statements in the CPG to find function calls and appropriately label the Statements.

[0058] Write-State-Analysis: When a victim contract is left in an inconsistent state, a reentrancy vulnerability occurs. As previously explained, this happens when the contract is unexpectedly re-entered after an external call and before the state is updated. HCC may follow the following two-step approach to effectively find the statements that update the state during the vulnerability detection process.

[0059] In the first analysis step, HCC collects all statements that change the state variables of the contract. Then, the collected statements and those Surround functions are labeled with WritesState, and an edge is added to the state variables being handled. This edge has the label WRITES.

[0060] In the second step of the write state analysis, HCC collects all internal function calls that call functions that update the contract state. Those calls and those Surround functions receive similar labels and edges as the above statements, but this second step is repeated until no new labels are added to the CPG.

[0061] As will become apparent, the CPG expansion process is tailored to the use cases of HCC. Detection of other types of vulnerabilities may have different requirements, and the CPG expansion may be extended to meet those requirements.

[0062] Vulnerability Detection In the vulnerability detection process according to an embodiment of the present invention, HCC searches for various vulnerability patterns in the code property graph. Whenever a subgraph matching a vulnerability pattern is found, the included graph nodes are collected and a new vulnerability node is inserted into the CPG. This vulnerability node has edges to all the included graph nodes. The number, label, and meaning of the edges depend on the type of vulnerability found.

[0063] Detection of Reentrancy: The detection of reentrant vulnerabilities may be performed as follows. First, HCC queries the CPG for the statement s that writes to a state w and Surround it function f. Then, HCC considers the control flow of f and searches for a transient path from an external call c e to s w through c e . HCC also captures the state variable sv handled by s w . When such a pattern is found, HCC queries the CPG for all functions f c that belong to the same contract and also write to sv. This approach is effective for detecting conventional reentrancy, cross-function reentrancy, and reentrancy in representative case (ii).

[0064] For the reentrancy in representative case (i), HCC queries the CPG for an external call c d that has a transient path to a representative call c e when considering the control flow.

[0065] The generation-based reentrancy detection in HCC may be performed in a manner similar to the basic detection described above. The statement s that writes to a statew and Surround it The CPG is queried for the function f. Generation-based reentrancy detection considers the control flow of f and, instead of external calls, the constructor call c c from s w transiently leading to c c is searched for. However, CPG-based analysis enables HCC to analyze the constructor being called. In this way, if the constructor contains an external call, HCC reports only this vulnerability. This is effective because without an external call, reentrancy does not occur. If the constructor calls an external function, HCC queries the CPG again for all functions that also write to sv and belong to the same contract.

[0066] Detection of integer bugs: Vulnerability detection for integer bugs may be performed as follows. HCC queries the CPG for all nodes representing either subtraction, addition, or multiplication that are part of an assignment statement. This is appropriate because if the result of the calculation is stored, only integer bugs can be harmful to the smart contract. HCC collects the calculation, its various representations, the assignment statement, and the representation to which the value is assigned.

[0067] To facilitate underflow patching, statements leading to the assignment statement are also collected.

[0068] Patching vulnerabilities To patch the detected vulnerabilities, HCC is repeated over all the vulnerability nodes inserted during the vulnerability detection process. Obviously, the application of the patch depends on the vulnerability to be patched.

[0069] Reentrant patching: HCC uses the same patch pattern for all reentrant methods except for the reentrancy of representative case (i). First, the general procedure will be described below, and then the procedure for the reentrancy of representative case (i) will be described.

[0070] Reentrancy consists of a state variable sv, a statement s that writes to this state variable w an external function call c e and Surround it a function f and a cross-function f that also writes to sv c Recall that it consists of a set of. As a first step, HCC generates a lock variable (l sv ) for sv as a state variable. This includes checking whether sv already has a lock variable. The type of variable l sv depends on the type of sv itself. For example, if sv has a basic type such as uint256, then l sv will be of boolean type, but for mapping types, only the value type will be of boolean type.

[0071] l sv After l is found or inserted into the CPG, HCC generates an assignment statement to set the state of l sv . The lock statement lock_l sv sets the state value to true, and the unlock statement unlock_l sv sets the state value to false. Then, HCC changes the control flow of f so that the lock statement, external call, and unlock statement are directly consecutive to each other as lock_l sv →c e →unlock_l sv .

[0072] After the control flow is changed, HCC checks that l sv is unlocked and inserts l svGenerate a guard to insert. The generation and insertion of the guard can also occur in all other functions f that write to sv c as well.

[0073] The patching for the reentrancy of the representative case (i) may be implemented in a slightly different way, and HCC cannot detect which state (or whether a state) was written in the representative call c d . Therefore, the patch is inserted into the main lock as a state variable. Then, the patch is around the external call c e as well as the representative call c d with lock statements and unlock statements for this lock. Then, guards for the main lock are inserted at the beginning of all publicly callable functions.

[0074] Patching integer bugs: Various integer bugs may be patched by inserting assertions. For multiplication and addition, the assertion is added after the operation in the control flow. For subtraction, the assertion is added before the operation in the control flow.

[0075] Regarding the evaluation of the validity and function accuracy, once a smart contract is patched, HCC may evaluate all existing transactions to confirm that the accuracy of the functions of the patched smart contract is maintained and that the vulnerability is accurately patched.

[0076] Since the patches applied by HCC must not break the functionality of the smart contract, HCC according to the embodiments may evaluate after the following aspects. - Patch effectiveness: Verify that HCC effectively patches known vulnerabilities available in the dataset. This includes reproducing available exploit transactions on the modified Ethereum node. - Function accuracy: Ensure that the HCC does not break the smart contract. To test this, all transactions of the original contract are executed in the patched contract. For this, a modified Ethereum node is also used.

[0077] Regarding the inspection of the implementation form of HCC according to an embodiment of the present invention, the prototype of HCC can be constructed in Kotlin, a language on the JVM. This prototype may rely on the Solidity compiler (see the Solidity programming language, available at https: / / github.com / ethereum / solidity / ) to generate the abstract syntax tree (AST) of the source file and issue it as JSON. HCC may consume the AST and construct a code property graph (CPG). This prototype may use Neo4j (see the Neo4j graph platform available at https: / / neo4j.com / ) to store and analyze the CPG.

[0078] Many modifications and other embodiments of the invention described herein will come to the mind of those skilled in the art of the technology related to the present invention, having the benefit of the teachings shown in the foregoing description and related drawings. Accordingly, it is to be understood that the invention is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used only in a general and descriptive sense and not for purposes of limitation.

Claims

1. A computer-implemented method for supporting a smart contract in a blockchain network, comprising: converting the source code of the smart contract into an abstract syntax tree model; generating a code property graph based on the abstract syntax tree model; executing an extension process to extend the code property graph using information inferable from the abstract syntax tree model; executing a vulnerability detection process, wherein the code property graph is inspected to determine whether there are one or more predetermined vulnerability patterns for finding one or more predetermined vulnerabilities; executing a vulnerability patching process, wherein one or more patches are applied to correct the vulnerabilities found in the vulnerability detection process, and the patches are inserted into the code property graph such that a patched code property graph is generated; wherein the step of executing the extension process includes call analysis, and the call analysis includes: iterating over function call expressions in the code property graph; assigning a call label to each external function call; A computer-implemented method.

2. The method according to claim 1, wherein the blockchain network is a distributed network having nodes, and the blockchain enables the nodes to participate in transactions with each other using cryptographically secure signatures.

3. The method according to claim 1 or 2, wherein whenever a transaction is sent to the address of the smart contract, the smart contract is triggered and executed in a virtual machine by a node that verifies and adds the transaction to the blockchain.

4. The method according to any one of claims 1 to 3, wherein the code property graph includes a combined representation of a control flow graph, a data flow graph, and / or a dominator tree.

5. The contains-call-analysis included in the step of executing the extension process includes: To find function calls, analyzing a sub - representation of statements in the code property graph; Assigning a call label to each statement having an external function call; The method according to any one of claims 1 to 4, comprising:

6. The write - state - analysis included in the step of performing the expansion process, Collecting statements that change state variables of the smart contract; Assigning a writes - state - label to the collected statements and the functions surrounding them; Collecting internal function calls that call functions to update / write state variables; Assigning a writes - state - label to the collected internal function calls and the functions surrounding them; The method according to any one of claims 1 to 5, comprising:

7. The method according to any one of claims 1 to 6, wherein the vulnerability pattern is associated with a predetermined vulnerability, and the predetermined vulnerability may include re - entrancy, integer overflow bug and / or integer underflow bug.

8. The method according to any one of claims 1 to 7, wherein the vulnerability pattern is represented in the form of a sub - graph, and the step of performing the vulnerability detection process includes searching for a sub - graph inside the code property graph of the smart contract.

9. The step of performing the vulnerability detection process, Statement s for writing a state w querying a code property graph for functions f surrounding them, and Consider the control flow of function f and external function call c e from s w to transiently communicate with c e searching step, and s w a step of taking in a state variable sv handled by All functions f that belong to the smart contract and write to sv c querying the code property graph for and The method according to any one of claims 1 to 8, comprising:

10. The step of performing the vulnerability detection process, Statement s for writing the state w and querying a code property graph for functions f surrounding them, and Considering the control flow of function f, constructor call c c transiently leads from w to s, and calls external function call c e The step of searching for constructor call c c and s w A step of taking in a state variable sv to be handled by w For all functions f that belong to the smart contract and write to sv c querying the code property graph for The method according to any one of claims 1 to 9, comprising:

11. The step of performing the vulnerability patching process to apply a patch, A lock variable l of sv as a state variable sv A step of providing, and l sv generating an assignment statement for setting the state of sv , the lock statement lock_l sv sets the value of the state to true, and the unlock statement unlock_l sv sets the value of the state to false, and steps The lock statement and the external function call c e or the constructor call c c and the unlock statement are lock_l sv →c e or c c →unlock_l sv and changing the control flow of function f so that they directly follow each other The method according to claim 9 or 10, comprising:

12. The method according to any one of claims 1 to 11, wherein the patch is specially created for the one or more vulnerability patterns.

13. The method according to any one of claims 1 to 12, wherein the code property graph with the patch is thoroughly examined to generate new source code for the smart contract incorporating the one or more applied patches.

14. A computer system for supporting smart contracts in a blockchain network, the computer system comprising, alone or in combination, a storage device and one or more processors configured to execute a method, in particular the method according to any one of claims 1 to 13, the method comprising converting the source code of a smart contract into an abstract syntax tree model; generating a code property graph based on the abstract syntax tree model; executing an expansion process of expanding the code property graph using information inferable from the abstract syntax tree model; executing a vulnerability detection process, wherein the code property graph is inspected to determine whether there are one or more predetermined vulnerability patterns for finding one or more predetermined vulnerabilities; executing a vulnerability patching process, wherein one or more patches are applied to correct the vulnerabilities found in the vulnerability detection process, and the patches are inserted into the code property graph such that a patched code property graph is generated; A computer system comprising the above.

Images