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 technology]

[0003] Since the inception and implementation of Bitcoin in 2009, cryptocurrencies have achieved widespread acceptance. Bitcoin was originally designed as a peer-to-peer payment infrastructure using a concept called blockchain as the enabling technology. A blockchain is an append-only distributed data structure that allows distrusting parties to engage in transactions with each other through the use of cryptographically secure signatures. Data can be stored on the blockchain in a cryptographically secure distributed manner, and participating nodes decide to add data by following a consensus protocol, such as proof of work or proof of contribution, to add data to the blockchain.

[0004] The new market brought about by the emergence of blockchain technology has grown to comprise more than 2,500 cryptocurrencies today. These so-called altcoins implement alternative blockchains to the Bitcoin infrastructure. In addition to payment infrastructure, some of these altcoins also provide a means for executing programs on the blockchain, typically referred to as smart contracts. One of the most prominent blockchain networks featuring smart contracts is the Ethereum blockchain. In the Ethereum blockchain, smart contracts are special bytecode programs that are triggered whenever a transaction is sent to the contract's address. Smart contracts are then executed in the Ethereum Virtual Machine (EVM) by the same nodes that validate and add transactions to the blockchain. To date, nearly 2 million smart contracts have been deployed on the Ethereum blockchain.

[0005] Ethereum smart contracts are Turing-complete programs that implement autonomous agents on the blockchain because they can manage their own Ether cryptocurrency and trigger further actions, such as generating transactions to other smart contracts to transfer Ether to another account or invoke other smart contracts. However, smart contracts are susceptible to programming errors, just like traditional software. In addition, semantic gaps arise when the transactional nature of blockchains is combined with incorrect assumptions about the programming model of smart contracts. One such incorrect assumption is that transactions sometimes execute sequentially, even though real-world transactions can initiate nested transactions. This ultimately leads to numerous bugs in smart contracts. Because smart contracts sometimes manage significant amounts of cryptocurrency, they are valuable targets for attackers seeking to exploit security vulnerabilities for direct financial gain. One of the first notorious events related to smart contract development was "TheDAO" hack, which resulted in the loss of Ether equivalent to US$50 million at the time of the incident (see Rob Price's non-patent document "Digital currency Ethereum is cratering because of a $50 million hack," June 2016, available at https: / / www.businessinsider.com / dao-hacked-ethereum-crashing-in-value-tens-of-millions-allegedly-stolen-2016-6). In this regard, attackers 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 a reentrancy vulnerability, this fact can be used to disable certain security-related checks in the victim smart contract's code.So in the case of "The DAO" hack, an attacker was able to exploit a reentrancy vulnerability to repeatedly withdraw a specific amount of ether.

[0006] Apart from reentrancy attacks, there are other issues such as integer bugs, e.g. integer overflow and underflow, access control and input validation bugs, to name a few. Recently, several efforts have been made to research new ways to prevent 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 literature is exemplarily referenced: - Christof Ferreira Torres, Julian Schutte et al., "Osiris: Hunting for Integer Bugs in Ethereum Smart Contracts", 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, CA, 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 of smart contracts before they are deployed. While static analysis and verification are most useful to smart contract developers, several dynamic analysis techniques have emerged that identify and prevent vulnerabilities during smart contract execution, similar to exploit mitigation mechanisms in traditional software. For example, Sereum has been proposed as a system that not only detects reentrancy attacks but also mitigates them through a runtime-enforced locking mechanism. In Sereum, all participating nodes must perform the analysis, and flagged transactions are not included in the blockchain. Similarly, Torres et al. (2019) proposes a solution in which vulnerability patterns are managed internally within the blockchain and approved or rejected by network participants through voting, in "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, pp. 2589-2591, DOI: 10.1145 / 3319535.3363263, URL: https: / / doi.org / 10.1145 / 3319535.3363263. However, such dynamic analysis techniques have not been shown to effectively integrate into the broader blockchain ecosystem because neither the source code nor the contract bytecode reflects the security policies enforced by the dynamic analysis system, widening the semantic gap. Vulnerability detection is a particularly important topic as the Ethereum blockchain prevents any changes to the code of deployed smart contracts by design, so even if a vulnerability is discovered in a smart contract, it is not easy to upgrade the smart contract.However, there are certain code patterns and Ethereum platform features that allow a contract to emulate the functionality required to make the contract upgradable. However, it is the contract developer's responsibility to apply this pattern correctly as needed. Therefore, given the risk of any bugs in smart contracts, it is important to harden the code of smart contracts. [Prior art documents] [Non-patent literature]

[0008] [Non-Patent Document 1] Rob Price, "Digital currency Ethereum is cratering because of a $50 million hack," 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. [Non-patent document 2] Christof Ferreira Torres, Julian Schutte et al., "Osiris: Hunting for Integer Bugs in Ethereum Smart Contracts," 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 [Non-patent document 3] Loi Luu et al., "Making Smart Contracts Smarter," in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. CCS'16. Vienna, Austria: ACM, 2016, pp. 254–269. [Non-patent document 4] Mark Mossberg et al., "Manticore: A User-Friendly Symbolic Execution Framework for Binaries and Smart Contracts", (July 2019), arXiv: 1907.03890[cs.SE] [Non-patent document 5] Sukrit Kalra et al., "ZEUS: Analyzing Safety of Smart Contracts," Proceedings of the 2018 Network and Distributed System Security Symposium, San Diego, CA, Internet Society, 2018 [Non-patent document 6] Petar Tsankov et al., "Security: Practical security analysis of smart contracts," in Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, ACM, 2018, pp. 67–82. [Non-Patent Document 7] Torres et al., "ZEGIS: Smart Shielding of Smart Contracts," in 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, pp. 25892591, DOI: 10.1145 / 3319535.3363263, URL: https: / / doi.org / 10.1145 / 3319535.3363263 [Non-patent document 8] Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli, "A Survey of Attacks on Ethereum Smart Contracts (SoK)", Lecture Notes in Computer Science, Magazine abbreviation: 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 Summary of the Invention [Problem to be solved by the invention]

[0009] In view of the above, it is therefore an object of the present invention to improve and further develop a method and computer system of the type initially described for supporting smart contracts in a blockchain network in such a way as to efficiently strengthen smart contracts, in particular to remedy possible vulnerabilities. [Means for solving the problem]

[0010] According to the present invention, the aforementioned objects are achieved by a computer-implemented method for supporting smart contracts in a blockchain network, the method comprising: Transforming 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 augmentation process that augments the code property graph with information inferable from the abstract syntax tree model; performing a vulnerability detection process, wherein the code property graph is examined for one or more predefined vulnerability patterns to find one or more predefined vulnerabilities; 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; Includes.

[0011] Furthermore, the aforementioned object is achieved by a computer system for supporting smart contracts in a blockchain network, the system including a storage device and one or more processors configured, alone or in combination, to perform a method, the method comprising: Transforming 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 augmentation process that augments the code property graph with information inferable from the abstract syntax tree model; performing a vulnerability detection process, wherein the code property graph is examined for one or more predefined vulnerability patterns to find one or more predefined vulnerabilities; 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; Includes.

[0012] Runtime or compiler-dependent policies are often used to implement defense mechanisms for native C / C++ software. However, the present invention first recognizes that in the context of smart contract hardening, smart contract developers may wish to consider semantic changes to their smart contracts. Rather than enforcing hardening policies by modifying the runtime environment or the semantics of bytecode instrumentation, embodiments of the present invention advocate rewriting the source code as the most transparent way to automatically harden smart contracts in an efficient manner. Rewriting the source code may maintain the testability of smart contracts and allow smart contract developers to continue to tolerate changes and their implications. To this end, the present invention translates / transforms the smart contract source code into an abstract syntax tree model, particularly by a compiler entity. The abstract syntax tree model is then converted into a code property graph, which may be used to analyze the smart contract being tested. Furthermore, an enrichment process is performed to enrich the code property graph with information inferable from / by the abstract syntax tree model. A vulnerability detection process is then performed to examine the code property graph for one or more predefined vulnerability patterns to find one or more potential predefined vulnerabilities. If a predefined vulnerability pattern is found, a vulnerability patching process is performed to apply one or more predefined patches to fix the one or more vulnerabilities found during the vulnerability detection process. The patches are inserted directly into the code property graph to generate a patched code property graph.

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

[0014] According to embodiments of the present invention, a blockchain network may be a distributed network having nodes, and the blockchain allows each node to participate in transactions with one another through the use of cryptographically secure signatures. Thus, a blockchain may be an append-only distributed data structure that allows distrusting parties to participate in transactions with one another through the use of cryptographically secure signatures. Data may be stored in a distributed, cryptographically secure manner on the blockchain, and participating nodes decide which data to add according to a consensus protocol, such as proof of work or proof of contribution, to add data to the blockchain.

[0015] According to embodiments of the present invention, a smart contract may be triggered whenever a transaction is sent to the address of the smart contract. The smart contract may be executed in a virtual machine by a blockchain node that validates and adds transactions to the blockchain. Thus, a smart contract may be a special bytecode program that is triggered whenever a transaction is sent to the address of the contract.

[0016] According to embodiments of the present invention, a code property graph may include a combined representation of a data flow graph, a control flow graph, and / or a dominator tree. Thus, a code property graph may combine three graph representations of code into a joint data structure. Thus, a code property graph (CPG) is a representation of a program that unifies various expectations on a program that may be realized by static analysis in general. A key advantage of the code property graph concept is that the proposed graph is language-independent. This allows for the reuse of many types of analysis, since analyses can be written for graphs without being language specific.

[0017] According to an embodiment of the present invention, performing the enrichment process may include call analysis, which may include iterating through all function call expressions in the code property graph and assigning a call label to each foreign function call, thereby gathering appropriate information for efficient application and use in the vulnerability detection process.

[0018] According to an embodiment of the present invention, performing the enrichment process may include a contains-call analysis, which may include analyzing subexpressions of all statements in the code property graph to find function calls and assigning a call label to each statement that has a function call, thereby collecting appropriate information for efficient application and use in the vulnerability detection process.

[0019] According to an embodiment of the present invention, the step of performing the enrichment process may include a write-state analysis. The write-state analysis may include collecting all statements that change state variables of the smart contract and assigning a writes-state label to the collected statements and their environment functions. The write-state analysis may further include collecting all internal function calls that invoke functions that update / write state variables and assigning a writes-state label to the collected internal function calls and their environment functions. Thus, it is possible to collect appropriate information for efficient application and use in the vulnerability detection process.

[0020] According to an embodiment of the present invention, vulnerability patterns may be associated with predetermined vulnerabilities. The predetermined vulnerabilities may include reentrancy, integer overflow bugs, and / or integer underflow bugs. Thus, vulnerability patterns are taken into account to detect important potential vulnerabilities in smart contracts.

[0021] According to an embodiment of the present invention, vulnerability patterns may be expressed in the form of CPG subgraphs. Furthermore, performing the vulnerability detection process may include searching for CPG subgraphs within the code property graph of the smart contract. Therefore, the concept of code property graph (CPG) can be introduced, allowing vulnerabilities to be formulated as searches for specific subgraphs that represent vulnerabilities. This provides efficient vulnerability detection. Once the code property graph enrichment process is complete, vulnerability patterns may be inspected in the vulnerability detection process. These vulnerability patterns may be expressed in the form of various subgraphs of the code property graph. The presence of a specific subgraph in the code property graph indicates that the smart contract is susceptible to the associated vulnerability. Once all patterns related to the vulnerability have been found, vulnerability discovery (i.e., the vulnerability detection process) can be terminated and a vulnerability patching process can be initiated.

[0022] According to an embodiment of the present invention, the step of performing the vulnerability detection process includes a statement s w and the environment function f. Then, taking into account the control flow of the function f, query the code property graph to find the foreign function call c in the code property graph. e From s w Transitionally leading to c e may be searched. w If such a pattern is found, all functions f belonging to the smart contract that write to sv are included. c In the vulnerability detection process for , the code property graph may also be queried. Therefore, reentrancy vulnerabilities may be detected efficiently. For this purpose, a state variable sv and a statement s that writes to the state variable sv are w and statements w Considering the environment function f and the control flow of f, the external function call c e From s w Transitionally leading to c eand the cross function f written to sv c A reentrant vulnerability pattern including the set of

[0023] According to an embodiment of the present invention, in the vulnerability detection process, a statement s w The code property graph may be queried for the environment function f. The creation-based reentrancy detection detects the constructor call c given the control flow of f instead of the outer call. c From s w Transitionally leading to c c The CPG-based analysis makes it possible to analyze the constructor being called. This way, the vulnerability may be reported only if the constructor contains an external call. This is useful because reentrancy cannot occur without an external call. If the constructor calls an external function, the control property graph may be queried again for all functions that belong to the same contract and also write to sv. Thus, reentrancy vulnerabilities can be detected efficiently.

[0024] According to an embodiment of the present invention, the step of performing a vulnerability patching process to apply a patch includes using a lock variable l for sv as a state variable in the code property graph. sv This may include checking whether sv already has a lock variable. If not, then sv is generated. The lock variable l sv The type of 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. sv After is found or inserted into the control property graph, an assignment statement is generated, which is sv To do this, use the lock statement lock_lsv Ga l sv The value of the state may be set to true by the unlock statement unlock_l sv may set this value to false. Then the control flow of function f passes through a lock statement, an external call, and an unlock statement in lock_l. sv →c e →unlock_l sv and immediately succeed each other. After the control flow is changed, sv Check that is unlocked and add l to the beginning of function f sv A guard may be created that inserts sv. The guard creation and insertion is performed on all other functions f that write to sv. c Therefore, reentrancy vulnerabilities may be patched efficiently.

[0025] According to embodiments of the present invention, predetermined patches may be specifically created for individual vulnerability patterns. Accordingly, embodiments of the present invention relate to a novel approach for detecting and fixing vulnerabilities in smart contracts at the source code level in an efficient manner. Embodiments of the present invention introduce the concept of code property graphs (CPGs), which allow for formulating vulnerabilities as searches for specific subgraphs that represent vulnerabilities. Code property graphs may be introduced to automatically generate source-level patches for those vulnerabilities.

[0026] Accordingly, embodiments of the present invention may include using a code property graph to search for specific subgraphs in the source code to automatically patch vulnerabilities in smart contracts at the source code level. During the patching process, embodiments of the present invention apply patches that fix all vulnerabilities and insert them directly into the CPG. In the above case, embodiments of the present invention comb through the patched CPG to generate new source code. The patched smart contract may then be tested against all known transactions to ensure that the contract works properly for benign transactions and prevents attacks.

[0027] According to embodiments of the present invention, the patched code property graph is traversed to generate new source code for the smart contract that incorporates one or more applied patches.

[0028] Further features, advantages and embodiments will be described or become apparent below.

[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. The patches are applied to source code, preserving source code inspectability. This allows developers to verify changes introduced by the HCC using the same methods previously used, such as manual code review, formal verification, or other analysis tools. In contrast to traditional static analysis tools, the HCC also strives to sufficiently harden smart contracts against certain classes of bugs. This disclosure focuses primarily on the automatic detection and prevention of specific vulnerabilities, such as reentrancy vulnerabilities and integer overflow and underflow bugs. However, the HCC may be designed into a modular framework, allowing for further vulnerability detection and patching procedures to be implemented with minimal effort. To this end, a static source code analysis technique is implemented based on a code property graph (CPG), which allows for vulnerability detection to be formulated as a query on a generalized graph representing the program. Smart contract developers may intend to use the HCC during the development and deployment of smart contracts to automatically introduce hardening patches. However, the HCC system may also be utilized to facilitate manual patching workflows for already deployed contracts that have been developed as upgradeable contracts (e.g., using the ZeppelinOS framework).

[0030] Since the goal is to maintain checkability regarding contract changes, an HCC according to an embodiment of the present invention uses source code as input and emits generated source code as output. In this way, developers can ensure that the HCC does not introduce semantic changes that affect benign transactions, thus maintaining behavioral consistency. Several intermediate steps may be performed. First, the source code is converted into an Abstract Syntax Tree (AST). Then, 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 handle several analyses, such as alias analysis. Because the CPG currently only represents the AST, it may be enriched with all information that can be inferred from the AST to enable such analyses. A pattern-based approach is then followed to find subgraphs in the CPG that are similar to a particular vulnerability. These subgraphs are considered candidate vulnerabilities. The HCC computer system may verify the absence of a specific vulnerability prevention mechanism to determine whether this subgraph requires a patch. If a candidate is found to be an actual vulnerability, HCC automatically applies a patch based on the patterns found. After applying a patch for each discovered vulnerability, HCC combs through the CPG to generate new source code that incorporates the patch.

[0031] Thus, embodiments of the present invention may provide a novel approach for detecting and fixing vulnerabilities in smart contracts at the source code level. This approach introduces the concept of code property graphs (CPGs), which allow vulnerabilities to be formulated as searches for specific subgraphs that represent vulnerabilities. Furthermore, CPGs can be deployed to automatically generate source-level patches for those vulnerabilities.

[0032] Embodiments of the present invention may enable the detection and patching of reentrancy and 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 advantageously design and further develop the teaching of the present invention. For this purpose, reference is made on the one hand to the dependent claims of claim 1 and on the other hand to the following description of further embodiments of the invention, which are shown by way of example in the figures. In connection with the description of further embodiments of the invention with the aid of the figures, further embodiments and further developments of the present teaching are generally described. [Brief explanation of the drawings]

[0035] [Figure 1] 1 illustrates example source code for one embodiment of the present invention, along with a schematic diagram of an exemplary application scenario that represents an attack on a reentrancy vulnerability in the SimpleDAO contract, where the second check (2) passes because it is performed on an inconsistent internal state. [Figure 2] 1 is a schematic diagram illustrating a method and system according to one embodiment of the present invention, which provides a Hardened Contract Compiler (HCC) architecture with a toolchain for automated discovery and patching of reentrancy vulnerabilities. DETAILED DESCRIPTION OF THE INVENTION

[0036] Ethereum smart contracts suffer from several types of bugs that lead to security vulnerabilities. Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli, "A Survey of Attacks on Ethereum Smart Contracts (SoK)", 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. Attacks range from denial of service, such as in the "KotET" contract, to making Ether unavailable and allowing attackers to steal it, as was the case with the Parity Multi-Sig wallet. In the infamous case of the "TheDAO" hack, attackers were able to transfer huge amounts of Ether through vulnerable contracts. The attack against "TheDAO" was possible due to a bug known as a reentrancy vulnerability.

[0037] Reentrancy occurs when a contract calls an external contract, which in turn calls the calling contract again within the same transaction. Hence the call graph A → B → A observed within a single transaction. Reentrancy is essential for the Withdrawal pattern and several other programming patterns, but can be exploited if not implemented carefully. The infamous attack against "TheDAO" demonstrated how weak implementations can lead to a massive loss of Ether.

[0038] To support safe reentrancy, Solidity supports several high-level concepts for invoking another contract: transfer, send, and call. All three are implemented as EVM-level CALL instructions, but the transfer and send functions differ in that they only provide a limited amount of gas. This gas limit prevents the called contract from executing other high-gas instructions, such as making further calls. However, using the wrong type of call can lead to a reentrancy vulnerability.

[0039] A reentrancy vulnerability occurs when a contract is unexpectedly re-entered and operates on some inconsistent internal state. Figure 1 shows a simplified version of the "TheDAO" contract from 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, which exhibits the same reentrancy vulnerability as the original "TheDAO" contract. Thus, Figure 1 is a schematic diagram illustrating an exemplary application scenario for one embodiment of the present invention, which illustrates an attack on the reentrancy vulnerability of the SimpleDAO contract. The SimpleDAO contract maintains internal state that records the amount of Ether contributed by contributors to SimpleDAO. Contributors are allowed to withdraw using the withdraw function. The withdraw function must perform three steps: (1) check whether the contributor is allowed to withdraw the requested amount of ether, (2) send the amount of ether to the contributor, and (3) update the internal state to indicate that the contributor now has less ether contributed to the SimpleDAO contract (see Figure 1). Note that in a vulnerable SimpleDAO, step (2) is executed before updating the state in (3). This means that a malicious contributor could re-enter the contract and call withdraw again, which would invoke check (2). However, because the internal state has not been updated to reflect the withdrawal in the previous withdraw call, the attacker would bypass the check and be allowed to withdraw that amount again. The internal state is only updated at the end.

[0040] An attacker can repeat the reentrancy until the entire SimpleDAO contract's ether is spilled. To correct the example in Figure 1, lines 3 and 4 (see the source code example represented by Figure 1) are swapped so that (3) executes before (2). This way, the second call to (1) operates in a consistent state, and the check should be useless.

[0041] The example in Figure 1 illustrates a classic reentrancy vulnerability. However, reentrancy can follow several different vulnerability patterns: - Classical reentrancy as illustrated by the example in Figure 1. - Cross-functional reentrancy, where two public functions of a victim contract independently write to the same state. These functions do not need to allow traditional reentrancy when used alone. - Representative reentrancy, which involves three contracts, one of which is used as a library by the victim contract. Even if the functions contained in the library and the victim contract do not allow traditional reentrancy, it is possible that the combination of these functions allows reentrancy. This occurs whenever the state update and external calls occur in separate functions, one of which is from the victim contract and the delegate calls that function. Representative reentrancy can occur in two different ways: (i) an external call occurs before a representative call occurs. The representative call operates in the called context and may change the state variables of the function. In this disclosure, this is referred to as "reentrancy of representative case (i)." (ii) a representative call occurs before the state update is performed. Because 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 of representative case (ii)." - Creation-based reentrancy that can occur when a contract creates a new contract before performing a state update. The constructor of the newly created contract can potentially perform an external call to a malicious contract.

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

[0043] While this disclosure focuses primarily on reentrancy vulnerabilities, embodiments of the present invention are designed to be extendable to other vulnerabilities. Many techniques exist for detecting reentrancy vulnerabilities in smart contracts. Many of these tools rely on symbolic execution, which leads to path explosion. However, many known tools work at the EVM level and have been found to suffer from inaccuracies. They either focus on contracts that have already been deployed and analyze at the EVM level, resulting in inaccuracies, or known tools generally fail to detect certain reentrancy patterns.

[0044] According to an embodiment of the present invention, a possible fix for a reentrancy vulnerability can be implemented by using a lock for a state variable. Bytecode analysis suffers from the drawback of lacking field sensitivity and resulting in a loss of reliability due to the lack of type information available at the EVM level. This loss of reliability can lead to more storage locking than is necessary at the EVM level. Locking storage more than necessary due to a loss of reliability can result in more false positives. By analyzing source code instead, type information is available, preventing the loss of reliability. Therefore, according to an embodiment, targeted source code patching is provided to provide patches with reduced overhead relative to patches generated at the bytecode level. Source code patching further enables developers to evaluate fixes added by an embodiment of the present invention before deploying a smart contract. To date, most solutions have focused on bytecode-level patching, which introduces significant overhead and, because they are performed only at the bytecode level, hinder developers from investigating the exact fixes introduced by the patch.

[0045] Known defense mechanisms often utilize compiler-based instrumentation to enforce their policies. Such approaches suffer from the drawback of being opaque, since the resulting binaries not only reflect the source code but also the (compiler-dependent) policies. While this may be acceptable in many application domains, smart contract developers require more transparency and control over the contract code. Therefore, by rewriting the source code in accordance with embodiments of the present invention instead of using instrumentation, the inspectability and modifiability of the source code are maintained. The overhead of source code patches in accordance with embodiments of the present invention is also often quite small, requiring only a few lines of code to effectively mitigate a vulnerability. Therefore, by rewriting the source code, developers can verify changes made by embodiments using the same methods as before, such as manual code review, formal verification, or other analysis tools.

[0046] Embodiments of the present invention present a hardened contract compiler (HCC) as a toolchain that automatically finds and fixes reentrancy vulnerabilities in source code, thus preserving testability, to prevent developers from deploying smart contracts susceptible to reentrancy attacks. While this disclosure focuses primarily on the automatic detection and prevention of reentrancy vulnerabilities and integer overflow and underflow vulnerabilities, the CPG-based approach according to embodiments of the present invention is designed to be extensible to other types of vulnerabilities. The primary purpose of the HCC is to enable security analysis of smart contracts to assist developers in developing new, secure smart contracts. However, a compilation toolchain according to embodiments can also be utilized to facilitate a manual patching workflow for already deployed contracts.

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

[0048] As shown in Figure 2, HCC takes the source code of a smart contract as input. First, the source code must be transformed into a model that facilitates analysis. The source code is first converted by a compiler into an Abstract Syntax Tree (AST) model, which is then analyzed to construct a basic form of a Code Property Graph (CPG). The CPG is a representation of a program that unifies various views of the program, typically achieved through static analysis. The CPG is then enriched with information that may already have been inferred from the AST. However, at this state, the CPG is essentially just another representation of the AST and may therefore already be augmented based on itself. The CPG then contains basic information necessary for much of the analysis, such as information about data flow.

[0049] Obviously, vulnerabilities must first be found before they can be patched. Once the CPG enrichment process is complete, the HCC examines vulnerability patterns in the vulnerability detection process. These vulnerability patterns can be expressed 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 have been found, vulnerability discovery is finished and the vulnerability patching process begins.

[0050] During the vulnerability patching process, the HCC applies and inserts patches that fix this vulnerability directly into the CPG. These patches are specifically created for each vulnerability pattern. When designing and applying patches, it is important to ensure that the fixes applied by the HCC do not break any desired functionality; for example, the business logic of the contract must remain intact.

[0051] The vulnerability patching process ends after applying the patching scheme to all previously found vulnerabilities. In this case, the HCC goes through the patched CPG to generate new source code. The rewritten source code can then be further examined and verified or compiled.

[0052] Basic CPG Structure: As shown in Figure 2, the basic CPG structure introduces an 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 code at the subexpression level and also across contract boundaries.

[0053] CPG Enrichment: During the CPG enrichment process, HCC can perform some analysis using 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 enrichment process may involve multiple analyses that make relevant information for reentrancy detection more accessible for further analysis. The enrichment process serves as a precursor to more advanced vulnerability detection.

[0054] In the following, we mainly focus on reentrancy vulnerabilities and integer overflow and underflow bugs. Therefore, the CPG enhancement process in HCC may include the following analysis:

[0055] Call-Analysis: When searching for reentrancy 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 as Externalcall. External calls are all calls that occur when a function of another contract is called directly or using the call and delegatecall functions associated with type address. The latter are labeled as Delegatecall as well as Externalcall. This is sufficient to detect the classic cross-function reentrancy vulnerability pattern and representative reentrancy vulnerability pattern introduced above. To also detect construction-based reentrancy, HCC labels NewExpressions as Constructorcall in the CPG if the type being constructed is defined by another contract. To generate new contracts using NewExpressions, the smart contract's code must be available in the CPG, which allows for analysis of functions across contract boundaries.

[0056] The HCC labels all function calls and then, where appropriate, labels the containing function with ContainsDelegateCall, ContainsExternalCall, and ContainsConstructorCall. Note that the HCC iterates over all function calls in the CPG, and that the environment functions of those function calls may be part of another contract. This means that a function called by a Constructorcall is either subject to this analysis or does not contain the function call.

[0057] Contains-Call-Analysis: HCC uses the call analysis described above to analyze function calls at the expression level. However, most expressions are subexpressions of statements, and this can also be the case of function calls, although this is unnecessary. Because statements are treated as atomic control flow units (equivalent to basic blocks) of functions in the CPG, it is easier to reason about function calls at the statement level during the vulnerability detection and patching process. Therefore, HCC analyzes the subexpressions of all statements in the CPG to find function calls and labels the statements appropriately.

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

[0059] In the first analysis step, HCC collects all statements that modify the state variables of the contract. The collected statements and their environment functions are then labeled with WritesState, and edges are added to the state variables they handle. These edges are labeled with WRITES.

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

[0061] As will become apparent, the CPG enrichment process is tailored to the HCC use case. Detection of other types of vulnerabilities may have different needs, and the CPG enrichment may be extended to address those needs.

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

[0063] Reentrancy detection: Reentrancy vulnerability detection may be performed as follows: First, the HCC detects a statement s that writes state. w and the environment function f. Then, the HCC determines the control flow of f and the external call c e From s w Transitionally leading to c e HCC is a w When such a pattern is found, the HCC also captures the state variables sv handled by f c Query the CPG for. This technique works for classical reentrancy as well as cross-function reentrancy and representative case (ii).

[0064] Regarding the reentrancy of the representative case (i), HCC considers the control flow of the representative call c d External call c transitively leads to e Query CPG for:

[0065] The detection of production-based reentrancy in HCC may be implemented much like the basic detection described above. wThe CPG is queried for the environment function f. Creation-based reentrancy detection considers the control flow of f as a constructor invocation c instead of an external call. c From s w Transitionally leading to c c However, CPG-based analysis allows HCC to analyze the constructor being called. This way, if a constructor contains an external call, HCC will only report this vulnerability. This is useful because without external calls there would be no reentrancy. If the constructor calls an external function, HCC will again query the CPG for all functions that belong to the same contract and also write to sv.

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

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

[0068] Vulnerability patching To patch the detected vulnerabilities, we iterate over all of the vulnerability nodes inserted during the vulnerability detection process. Obviously, patch application depends on the vulnerability being patched.

[0069] Patching Reentrancy: HCC uses the same patch pattern for all reentrancy schemes except for representative case (i) reentrancy. In the following, the general procedure is first described, followed by the procedure for representative case (i) reentrancy.

[0070] Reentrancy is defined as a state variable sv and a statement s that writes to this state variable. w and the external function call c e and the environment function f and the cross function f, which is also written to sv. c As a first step, HCC considers the lock variables (l) of sv as state variables. sv ), which includes checking whether sv already has a lock variable. sv The type of 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 type of the value will be of Boolean type.

[0071] l sv After being found or inserted into the CPG, HCC sv Generates an assignment statement that sets the state of the lock statement lock_l sv sets the state value to true and the unlock statement unlock_l sv sets the value of the state to false. Then, the HCC checks whether the lock statement, the external call, and the unlock statement are sv →c e →unlock_l sv and f directly succeed each other.

[0072] After the control flow is changed, the HCC sv Check that is unlocked and add l to the beginning of function f sv The guard generation and insertion is performed on all other functions f that write to sv. c It can also occur.

[0073] The patch for reentrancy in representative case (i) can be implemented in a slightly different way, with the HCC being the representative call c dTherefore, the patch is inserted into the main lock as a state variable. The patch then calls the external call c with lock and unlock statements for this lock. e and representative call c d Then a guard for the main lock is inserted at the beginning of every publicly callable function.

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

[0075] With respect to validity and functional correctness evaluation, once a smart contract is patched, the HCC may evaluate all existing transactions to ensure that the functional correctness of the patched smart contract is maintained and that vulnerabilities have been correctly patched.

[0076] Since patches applied by the HCC must not break the functionality of the smart contract, the HCC according to the embodiment may be evaluated after the following aspects: - Patch Effectiveness: Verify that the HCC effectively patches known vulnerabilities available in the dataset, including replaying available exploit transactions on a modified Ethereum node. - Functional correctness: Ensure that the HCC does not break the smart contract. To check this, all transactions of the original contract are executed in the patched contract. For this purpose, a modified Ethereum node is also used.

[0077] Regarding examining an implementation of HCC according to one embodiment of the present invention, a prototype of HCC can be built in Kotlin, a language on the JVM. This prototype may rely on the Solidity compiler (see Solidity Programming Language, available at https: / / github.com / ethereum / solidity / ) to generate an Abstract Syntax Tree (AST) of a source file and emit it as JSON. The HCC may consume the AST and build a Code Property Graph (CPG). This prototype may use Neo4j (see Neo4j Graph Platform, available at https: / / neo4j.com / ) to store and parse the CPG.

[0078] Many modifications and other embodiments of the inventions described herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. It is to be understood, therefore, that the inventions are 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 in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. 1. A computer-implemented method for supporting smart contracts in a blockchain network, comprising: translating a 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 using information inferable from the abstract syntax tree model; performing a vulnerability detection process, wherein the code property graph is examined for one or more predefined vulnerability patterns to find one or more predefined vulnerabilities; performing a vulnerability patching process, where 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; and performing the enrichment process includes performing invocation analysis, the invocation analysis including: iterating over function call representations in the code property graph; assigning a call label to each external function call; 4. A computer-implemented method comprising:

2. 2. The method of claim 1, wherein the blockchain network is a decentralized network having nodes, the blockchain enabling the nodes to engage in transactions with one another through the use of cryptographically secure signatures.

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

4. The method of claim 1 , wherein the code property graph comprises a combined representation of a control flow graph, a data flow graph and / or a dominator tree.

5. The step of performing the enrichment process includes a contains-call-analysis, analyzing sub-expressions of statements in the code property graph to find function calls; assigning a call label to each statement having an external function call; 5. The method according to claim 1 , comprising:

6. The step of performing the enrichment process includes write-state-analysis, collecting statements that modify state variables of a smart contract; assigning a writes-state-label to the collected statements and their surrounding functions; collecting internal function calls that call functions that update / write state variables; assigning a writes-state-label to the collected internal function calls and their surrounding functions; 6. The method according to any one of claims 1 to 5, comprising:

7. The method of any one of claims 1 to 6, wherein the vulnerability pattern is associated with a predefined vulnerability, the predefined vulnerability may comprise a reentrancy, an integer overflow bug and / or an integer underflow bug.

8. 8. The method of claim 1, wherein the vulnerability pattern is expressed in the form of a subgraph, and the step of performing the vulnerability detection process comprises searching a subgraph within a code property graph of the smart contract.

9. The step of performing the vulnerability detection process includes: Statements that write state w and querying the code property graph for a function f that surrounds them; Considering the control flow of function f, call external function c e From w Transitionally leading to c e searching for s w and taking in the state variables sv handled by All functions f belonging to the smart contract that write to sv c Querying the code property graph for 9. The method of any one of claims 1 to 8, comprising:

10. The step of performing the vulnerability detection process includes: Statements that write state w and querying the code property graph for a function f that surrounds them; Consider the control flow of function f. c From w Transitively through external function call c e Constructor call c c searching for s w and taking in the state variables sv handled by All functions f belonging to the smart contract that write to sv c Querying the code property graph for 10. The method of any one of claims 1 to 9, comprising:

11. executing the vulnerability patching process to apply a patch, The lock variable l of sv as the state variable sv and l sv generating an assignment statement that sets the state of lock_l sv sets the value of the state to true, and the unlock statement unlock_l sv setting the value of said state to false; The lock statement and the external function call e , or the constructor call c c and the unlock statement is lock_l sv →c e , or c c →unlock_l sv and modifying the control flow of function f so that they immediately follow each other.

11. The method of claim 9 or 10, comprising:

12. The method of claim 1 , wherein the patch is created specifically for the one or more vulnerability patterns.

13. 13. The method of any one of claims 1 to 12, wherein the patched code property graph is traversed to generate new source code for the smart contract that incorporates the one or more applied patches.

14. A computer system for supporting smart contracts in a blockchain network, the computer system comprising a storage device and one or more processors configured to execute, alone or in combination, a method, in particular a method according to any one of claims 1 to 13, the method comprising: translating a 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 using information inferable from the abstract syntax tree model; performing a vulnerability detection process, wherein the code property graph is examined for one or more predefined vulnerability patterns to find one or more predefined vulnerabilities; performing a vulnerability patching process, where 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; 2. A computer system comprising:

Images