Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
METHOD AND SYSTEM FOR REDUCING GAS CONSUMPTION IN ETHEREUM SMART CONTRACTS

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The disclosure herein generally relates to blockchain networks, and, more particularly, to reducing gas consumption in Ethereum smart contracts.

BACKGROUND
[002] Smart contracts are computer programs stored on a blockchain and are executed when predetermined conditions are met. Due to their nature and possibilities they offer, their popularity is increasing day by day. Ethereum smart contracts are permissionless contracts on Ethereum blockchain, and are accessible to any user on the blockchain. To pay miners for their work (costly resources) and to stop users from consuming too much of replicated storage and computation power, Ethereum blockchain implements the notion of gas and charges its users in terms of its native currency Ether. Gas is a unit that measures the amount of computational effort required to execute each operation. As the blockchains and in turn the smart contracts store sensitive data and may also hold and manage Billions of Dollars in the form of cryptocurrencies/tokens, they are target of attackers, causing huge financial and reputational losses.
[003] In several instances attackers have exploited programming errors related to arithmetic overflow/underflow to steal cryptocurrencies or generate huge amount of currencies/tokens. Despite good programming practices known to avoid arithmetic overflow/underflow errors, smart contracts are found to suffer from such types of errors. Therefore, to secure Ethereum smart contracts from attacks that are resulting from arithmetic overflow/underflow error, recent versions of an Ethereum Virtual Machine (EVM) that is part of the Ethereum blockchain network checks every arithmetic operation at run-time to ensure that the operation does not result in overflow/underflow, and when the EVM encounters an arithmetic overflow/underflow error, it reverts the transaction involving the operation. However, disadvantage of this approach is that it increases the gas cost as the checks performed by the EVM for each operation consumes more gas. As a result, the charges to be paid by a user to invoke a transaction as well increases, and thereby increasing overall cost of execution of smart contract transactions.

SUMMARY
[004] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a processor implemented method of reducing gas consumption in Ethereum smart contracts is provided. The method includes obtaining, via one or more hardware processors, a source code as input. Further, a plurality of arithmetic operations (AOs) in the source code are identified via the one or more hardware processors. Further, each of the plurality of AOs is classified as a safe AO, an arithmetic overflow/underflow error, or an alarm by processing the source code using one or more code analysis techniques, via the one or more hardware processors. Further, an automated source code transformation is performed, via the one or more hardware processors, to include the safe AOs inside unchecked blocks in the source code, wherein the safe AOs included inside the unchecked blocks are not checked for an arithmetic overflow error detection and an arithmetic underflow error detection by an Ethereum Virtual Machine (EVM) at runtime, reducing gas consumption during execution of transactions of the Ethereum smart contract.
[005] In another embodiment, wherein processing the source code using one or more code analysis techniques comprises obtaining an initial classification of each of the AOs as being one of the safe AO, arithmetic overflow/underflow error, or alarm, wherein the initial classification is obtained by processing the plurality of AOs using at least one static code analysis technique from a first set of code analysis techniques from among the one or more code analysis techniques, and then processing each of the AOs classified as the alarm in the initial classification, by performing an infeasibility analysis, comprising determining if each of the AOs classified as the alarm appears in one of a plurality of code patterns present in a reference code patterns set, wherein each of the AOs appearing in one of the plurality of code patterns present in the reference code patterns is re-labelled as the safe AO.
[006] In yet another aspect, performing the automated source code transformation based on the safe AOs involves generating one or more code repair instructions corresponding to each of the safe AOs, wherein the one or more code repair instructions specify code changes required to include each of the safe AOs inside the unchecked blocks, wherein the one or more code repair instructions are generated using one or more strategies from a set of predefined and configurable strategies for code repair, wherein the one or more strategies are selected based on a type of the statement of a code surrounding the safe AO, and presence or absence of one or more other safe and unsafe AOs in the code surrounding the safe AO. Further, the source code is modified based on the generated one or more code repair instructions to generate an output source code.
[007] In yet another embodiment, a system for Ethereum gas optimization is provided. The system includes one or more hardware processors, a communication interface, and a memory storing a plurality of instructions, wherein the plurality of instructions when executed, cause the one or more hardware processors to initially obtain a source code as input. Further, a plurality of arithmetic operations (AOs) in the source code are identified via the one or more hardware processors. Further, each of the plurality of AOs is classified as a safe AO, an arithmetic overflow/underflow error, or an alarm by processing the source code using one or more code analysis techniques, via the one or more hardware processors. Further, an automated source code transformation is performed, via the one or more hardware processors, to include the safe AOs inside unchecked blocks in the source code, wherein the safe AOs included inside the unchecked blocks are not checked for an arithmetic overflow error detection and an arithmetic underflow error detection by an Ethereum Virtual Machine (EVM) at runtime, reducing gas consumption during execution of transactions of the Ethereum smart contract.
[008] In another embodiment, the system processes the source code using one or more code analysis techniques to obtain an initial classification of each of the AOs as being one of the safe AO, arithmetic overflow/underflow error, or alarm, wherein the initial classification is obtained by processing the plurality of AOs using at least one static code analysis technique from a first set of code analysis techniques from among the one or more code analysis techniques, and then by processing each of the AOs classified as the alarm in the initial classification, by performing an infeasibility analysis, comprising determining if each of the AOs classified as the alarm appears in one of a plurality of code patterns present in a reference code patterns set, wherein each of the AOs appearing in one of the plurality of code patterns present in the reference code patterns is re-labelled as the safe AO.
[009] In yet another aspect, the system performs the automated source code transformation based on the safe AOs by generating one or more code repair instructions corresponding to each of the safe AOs, wherein the one or more code repair instructions specify code changes required to include each of the safe AOs inside an unchecked blocks, wherein the one or more code repair instructions are generated one or more strategies from a set of predefined and configurable strategies for code repair, wherein the one or more strategies are selected based on a type of the statement of a code surrounding the safe AO, and presence or absence of one or more other safe and unsafe AOs in the code surrounding the safe AO. Further, the source code is modified based on the generated one or more code repair instructions to generate an output source code.
[0010] In yet another aspect, a non-transitory computer readable medium for reducing gas consumption in Ethereum smart contracts is provided. The non-transitory computer readable medium includes a plurality of instructions when executed, cause one or more hardware processors to obtain a source code as input. Further, a plurality of arithmetic operations (AOs) in the source code are identified via the one or more hardware processors. Further, each of the plurality of AOs is classified as a safe AO, an error, or an alarm by processing the source code using one or more code analysis techniques, via the one or more hardware processors. Further, an automated source code transformation is performed, via the one or more hardware processors, to include the safe AOs inside unchecked blocks in the source code, wherein the safe AOs included inside the unchecked blocks are not checked for an arithmetic overflow error detection and an arithmetic underflow error detection by an Ethereum Virtual Machine (EVM) at runtime, reducing gas consumption during execution of transactions of the Ethereum smart contract.
[0011] In another aspect, the non-transitory computer readable medium causes processing of the source code using one or more code analysis techniques to obtain an initial classification of each of the AOs as being one of the safe AO, arithmetic overflow/underflow error, or alarm, wherein the initial classification is obtained by processing the plurality of AOs using at least one static code analysis technique from a first set of code analysis techniques from among the one or more code analysis techniques, and then processing each of the AOs classified as the alarm in the initial classification, by performing an infeasibility analysis, comprising determining if each of the AOs classified as the alarm appears in one of a plurality of code patterns present in a reference code patterns set, wherein each of the AOs appearing in one of the plurality of code patterns present in the reference code patterns is re-labelled as the safe AO.
[0012] In yet another aspect, the non-transitory computer readable medium causes performing the automated source code transformation based on the safe AOs by generating one or more code repair instructions corresponding to each of the safe AOs, wherein the one or more code repair instructions specify code changes required to include each of the safe AOs inside an unchecked block, wherein the one or more code repair instructions are generated one or more strategies from a set of predefined and configurable strategies for code repair, wherein the one or more strategies are selected based on a type of the statement of a code surrounding the safe AO, and presence or absence of one or more other safe and unsafe AOs in the code surrounding the safe AO. Further, the source code is automatically modified based on the generated one or more code repair instructions to generate an output source code
[0013] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[0015] FIG. 1 illustrates an exemplary system for reducing gas consumption in Ethereum smart contracts, according to some embodiments of the present disclosure.
[0016] FIG. 2 is a flow diagram depicting steps involved in the process of reducing gas consumption in Ethereum smart contracts, by the system of FIG. 1, according to some embodiments of the present disclosure.
[0017] FIG. 3 is a flow diagram depicting steps involved in the process of infeasibility analysis performed by the system of FIG. 1, according to some embodiments of the present disclosure.
[0018] FIG. 4 is a flow diagram depicting steps involved in the process of automated source code transformation, by the system of FIG. 1, according to some embodiments of the present disclosure.
[0019] FIG. 5 is an example implementation of the system of FIG. 1, according to some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[0020] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
[0021] To secure Ethereum smart contracts from attacks that are resulting from arithmetic overflow/underflow, an Ethereum Virtual Machine (EVM) that is part of the Ethereum blockchain network checks every arithmetic operation at run-time to ensure that the operation does not result in arithmetic overflow/underflow error (also referred to as ‘arithmetic overflow error or arithmetic underflow error’ in the description and claims), and when the EVM encounters an arithmetic overflow/underflow, it reverts the transaction involving the operation. However, disadvantage of this approach is that it increases the gas cost as the checks performed by the EVM for each operation consumes more gas. As a result, the charges to be paid by a user to invoke a transaction increases overall cost of execution of the transaction.
[0022] To solve this, system disclosed herein provides a method which involves classifying each Arithmetic Operation (AO) in a source code being processed, as safe AO, an arithmetic overflow/underflow error, or as an alarm. Further, an automated source code transformation is performed which involves generating one or more code repair instructions corresponding to each of the safe AOs, wherein the one or more code repair instructions specify code changes required to include/enclose each of the safe AOs inside an unchecked block in the source code, wherein the one or more code repair instructions are generated using a combination of strategies from a set of strategies, wherein the combination of strategies is automatically selected based on type of the statement of the safe AO and the code surrounding to the safe AO. Further, the source code is modified based on the generated one or more code repair instructions to generate an output source code.
[0023] Referring now to the drawings, and more particularly to FIG. 1 through FIG. 5, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[0024] FIG. 1 illustrates an exemplary system for reducing gas consumption in Ethereum smart contracts, according to some embodiments of the present disclosure. The system 100 includes or is otherwise in communication with hardware processors 102, at least one memory such as a memory 104, an I/O interface 112. The hardware processors 102, memory 104, and the Input /Output (I/O) interface 112 may be coupled by a system bus such as a system bus 108 or a similar mechanism. In an embodiment, the hardware processors 102 can be one or more hardware processors.
[0025] The I/O interface 112 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface 112 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a printer and the like. Further, the I/O interface 112 may enable the system 100 to communicate with other devices, such as web servers, and external databases.
[0026] The I/O interface 112 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the I/O interface 112 may include one or more ports for connecting several computing systems with one another or to another server computer. The I/O interface 112 may include one or more ports for connecting several devices to one another or to another server.
[0027] The one or more hardware processors 102 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, node machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors 102 is configured to fetch and execute computer-readable instructions stored in the memory 104.
[0028] The memory 104 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, the memory 104 includes a plurality of modules 106.
[0029] The plurality of modules 106 include programs or coded instructions that supplement applications or functions performed by the system 100 for executing different steps involved in the process of reducing gas consumption in Ethereum smart contracts, being performed by the system 100. The plurality of modules 106, amongst other things, can include routines, programs, objects, components, and data structures, which performs particular tasks or implement particular abstract data types. The plurality of modules 106 may also be used as, signal processor(s), node machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the plurality of modules 106 can be used by hardware, by computer-readable instructions executed by the one or more hardware processors 102, or by a combination thereof. The plurality of modules 106 can include various sub-modules (not shown). The plurality of modules 106 may include computer-readable instructions that supplement applications or functions performed by the system 100 for reducing gas consumption in Ethereum smart contracts.
[0030] The data repository (or repository) 110 may include a plurality of abstracted piece of code for refinement and data that is processed, received, or generated as a result of the execution of the plurality of modules in the module(s) 106.
[0031] Although the data repository 110 is shown internal to the system 100, it will be noted that, in alternate embodiments, the data repository 110 can also be implemented external to the system 100, where the data repository 110 may be stored within a database (repository 110) communicatively coupled to the system 100. The data contained within such external database may be periodically updated. For example, new data may be added into the database (not shown in FIG. 1) and/or existing data may be modified and/or non-useful data may be deleted from the database. In one example, the data may be stored in an external system, such as a Lightweight Directory Access Protocol (LDAP) directory and a Relational Database Management System (RDBMS). Functions of the components of the system 100 are now explained with reference to steps in flow diagrams in FIG. 2 through FIG. 4.
[0032] An example implementation of the system 100 is depicted in FIG. 5. Various modules/components of the system 100, i.e. an AO identifier 502, a static analysis module 504, an instruction generation module 506, and the automated code repair module 508, as depicted in FIG. 5, are implemented using the one or more hardware processors 102.
[0033] FIG. 2 is a flow diagram depicting steps involved in the process of reducing gas consumption in Ethereum smart contracts, by the system of FIG. 1, according to some embodiments of the present disclosure.
[0034] In an embodiment, the system 100 comprises one or more data storage devices or the memory 104 operatively coupled to the processor(s) 102 and is configured to store instructions for execution of steps of method 200 as in FIG. 2 by the processor(s) or one or more hardware processors 102. The steps of the method 200 of the present disclosure will now be explained with reference to the components or blocks of the system 100 as depicted in FIG. 2 and the steps of flow diagrams as depicted in FIG. 3 and FIG. 4. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods, and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps to be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
[0035] At step 202 of a method 200 in FIG. 2, the system 100 obtains a source code as input. In an embodiment, the source code is of an Ethereum smart contract. Further, at step 204 of the method 200, the system 100 identifies, via the one or more hardware processors, a plurality of arithmetic operations (AOs) in the source code. The system 100 may use any suitable code analysis/parsing technique to analyze the source code and identify the AOs. In the example implementation, the steps 202 and 204 are performed by the AO identifier 502. Further, at step 206 of the method 200, the system 100 classifies, via the one or more hardware processors, each of the plurality of AOs as a safe AO, an arithmetic overflow/underflow error (alternately referred to as ‘error’), or an alarm, by processing the source code using one or more code analysis techniques. Various steps involved in processing the source code using the one or more code analysis techniques are depicted in method 300 in FIG. 3 and are explained hereafter. At step 302 of the method 300, the system 100 obtains an initial classification of each of the AOs as being one of the safe AO, error, or alarm, wherein the initial classification is obtained by processing the plurality of AOs using at least one static code analysis technique from a first set of code analysis techniques from among the one or more code analysis techniques. The first set of code analysis techniques include but are not limited to data flow analysis, structural analysis, abstract interpretation, model checking, and symbolic execution. Static code analysis techniques in the first set of code analysis techniques classify an AO as an alarm if the AO cannot be classified either as safe or as an error, wherein an alarm denotes a warning to a user of the system 100 to manually inspect the source code and manually classify the AO corresponding to the alarm either as safe AO or as an error. In the practical implementation, the step 206 is executed by the static analysis module 504. Further, at step 304 of the method 300, the system 100 processes each of the AOs classified as the alarm in the initial classification, by performing an infeasibility analysis. Checking if an AO appears in a code pattern in the reference code patterns set by the infeasibility analysis comprises identifying a code surrounding to the AO determined by one of the several ways consisting of a pre-defined number of words (for example two on each side of the AO), code slicing, code at the level of block, function, or a loop, or a specific operation like arithmetic operation and checking whether the AO appears in in the identified code, wherein each of the AOs appearing in one of the plurality of code patterns present in the reference code patterns is re-labelled as the safe AO. The infeasibility analysis thus acts as an additional filtering, and by re-labelling at least a few of the AOs originally classified as alarms as safe AOs, checking of such AOs may be avoided, resulting in further reduction in gas consumption. Classification of the AOs, obtained after the re-labelling, is further processed at step 208 of the method 200, for the automated source code transformation. Thus the infeasibility analysis acts as a filtering step to identify more AOs as safe, and thereby filtering out the AOs that need not be checked by the EVM.
[0036] The infeasibility analysis is designed to reduce the AO alarms generated by the other source code analysis techniques or the AOs identified in the absence of those code analysis techniques. Each of the reference set of code patterns used during the infeasibility analysis indicates a code pattern for an alarm AO or unclassified AO (i.e., a potential overflow/underflow error case), where although theoretically it may be possible to occur the overflow/underflow error, in practice it may be impossible for this overflow/underflow error to occur, due to restrictions added by the EVM or due to unavailability of required computational resources. Since these cases cannot occur in practice, the infeasibility analysis identifies such patterns of AOs and marks them as safe AOs, to further reduce the gas consumption and thus the associated cost. Such cases which are impossible/unlikely to occur in practice are called “infeasibility-based safe AOs”. The infeasibility-based safe AOs (ISAOs) are identified based on several factors such as but not limited to the sources of values taken by the variables involved in the AOs, number of tokens in circulation, and a context of the code in which the AOs are present. Such factors individually or in combination form the reference code patterns in the reference code patterns set.
[0037] In an alternate embodiment, the system 100 may directly perform the infeasibility analysis on the AOs identified from the source code via step 204, during which the initial classification itself is performed by the infeasibility analysis.
[0038] In an embodiment, the reference code patterns in the reference code patterns set is configurable to enable or disable each of those patterns, add new patterns, or delete an existing pattern. Examples of patterns in the reference code patterns set are discussed below.
Pattern 1: Loop counter
[0039] The loops in smart contracts are typically written with a counter variable of uint256 datatype. If a loop counter is initialized with 0 and the upper bound is unbounded, theoretically the loop can run 2256-1 times, and thus the increment operation on the loop counter is identified as potential overflow/underflow error. This number, the number of times the loop can be executed, is such a large number that it will take billions of years to reach to that value through unary increment operation before the increment operation can result in the arithmetic overflow/underflow error. Such time duration is infeasible and the notion of gas bound/limit also makes it difficult to execute loops for a large number of times. Therefore, the infeasibility analysis marks such increment operation as safe AO. If the loop counter is not initialized with lower constant value or the initialized value is not known or the loop counter variable’s datatype is the lower-size datatype, then the AO corresponding to the increment operation is not classified as safe AO. For example, different code patterns are shown in Table.1 depicting AOs that can be marked and cannot be marked as safe AOs (ISAOs) by the infeasibility analysis.

Pattern 2: Increment of a variable inside loop

[0040] In this pattern, if a variable of unit/unit256 datatype is initialized with 0 or lower value and incremented inside a loop, the increment AO is marked as ISAO by the infeasibility analysis since this case is similar to the case discussed in pattern 1 (loop counter). If the same variable is assigned in the same loop with a variable whose values cannot be known, the increment operation is not marked as safe/ISAO. Examples of this pattern are shown in Table. 2.

Pattern 3: Increment of variable per transaction

[0041] In this type of pattern, a variable of datatype uint/uint256 is initialized with 0 or a small value (i.e., a value smaller than a threshold), and is updated only via unary increments or decrements. If such increment operations are performed inside an transaction, it is impractical to result the increment operation into an AO error, because for this error to occur billions of transactions need to be performed and it is infeasible in practice. Therefore, the infeasibility analysis classifies the AO on line 6 of the example code given in Table. 3 as safe AO, while the AO corresponding to the decrement operation is not classified as safe AO by the infeasibility analysis as it feasible that the variable has 0 value and deleteUser transaction gets invoked.

Pattern 4: Limited supply of balance

[0042] Typically, smart contracts hold and maintain balances/tokens of several users and they are updated through transactions that are like transfer of token/cryptocurrency from one user to another. The code example in Table. 4 shows a smart contract that has a transaction “transfer” which a user can invoke to transfer tokens from his/her to another recipient. Source code analysis techniques are capable of identifying the subtraction operation on line 13 as safe since there is a corresponding check on line 12. However, these techniques cannot identify the addition operation on line 14 as safe, because the balance of the recipient is unknown. The infeasibility analysis takes into account the fact that the “balances[to]” and “value” at max can be the “totalSupply”, and hence the addition operation cannot ever result into an arithmetic overflow. Therefore, it marks the addition operation as ISAO. Note that the implementation of the contract shown is such that, although any user is allowed to transfer tokens to any other user, the total supply of tokens remains the same.

1. contract SampleContract{
2. uint256 public datboiSupply = 10000000000;
3. uint256 public totalSupply;
4. mapping(address => uint256) public balances;
5.
6. function SampleContract {
7. totalSupply = datboiSupply * 20000;
8. Balances[msg.sender] = totalSupply;
9. }
10.
11. function transfer(address to, uint value) public {
12. if(balances[msg.sender] > value) {
13. balances[msg.sender] -= value;
14. balances[to] += value;
15. }
16. }
17. }

Table. 4
Pattern 5: User-provided bounded variables

[0043] In this type of pattern, the infeasibility analysis takes inputs from the user to identify the variables whose values are bounded and uses these details to identify safe AOs that are based on these bounded variables. The existing code analysis techniques cannot identify the multiplication operation on line 5 as safe since the values provided to the input variables “receiversCount” and “value” can be any values.
[0044] The infeasibility analysis takes inputs from user about the input and other variables in terms of whether they are bounded variables (e.g., value is a bounded variable since it denotes balance/tokens to be transferred), denotes size of a data structure (e.g., receiversCount denote the size of the receivers array) and their upper limits if they are known. Using these details, the infeasibility analysis marks the multiplication operation as ISAO, because the number of receivers is always limited as they are received as inputs for the transaction.

1. contract SampleContract{
2.
3.
4. function proxytransfer(uint receiversCount, address[] receivers, uint value) public {
5. uint someValue = 3 * receiversCount;
6. … // transfers value to receivers[i]
7. }
8. }

Table. 5
[0045] Referring back to method 200 in FIG. 2, at step 208 of the method 200 the system 100 performs, via the one or more hardware processors, the automated source code transformation to include each of the safe AOs (classified in step 206) inside an unchecked block, in the source code, wherein the AOs (i.e. the safe AOs) included inside the unchecked blocks are not checked for arithmetic overflow/underflow error detection by an Ethereum Virtual Machine (EVM) at runtime reducing gas consumption during execution of transactions of the smart contract. Various steps involved in the process of the automated source code transformation are depicted in method 400 in FIG. 4, and are explained hereafter. A statement is called safe statement if that statement has arithmetic operations and all those operations are classified as safe. An AO that is classified as an error or an alarm by a code analysis technique is called “unsafe AO”. A statement is called unsafe statement if it has at least one unsafe AO appearing on it. A statement is called no-POI statement if the statement does not have any arithmetic operation.
[0046] At step 402 of the method 400, the system 100 generates one or more code repair instructions corresponding to each of the safe AOs that are to be enclosed inside an unchecked block, wherein the one or more code repair instructions specify code changes required to include each of the safe AOs inside the unchecked block, wherein the one or more code repair instructions are generated using one or more strategies from a set of predefined and configurable strategies for code repair, wherein the one or more strategies are selected based on a type of the statement of a code surrounding the safe AO, and presence or absence of one or more other safe and unsafe AOs in the code surrounding the safe AO. Further, at step 404 of the method 400, the system 100 automatically modifies the source code based on the code repair instructions. As programming approaches used for generating the source code maybe different from time to time, based on nature/characteristics of the source code, different strategies may be used by the system 100 for performing the automated source code transformation. Examples of such strategies are given below:
[0047] To repair a safe AO, i.e. to add the safe AO inside an unchecked block, strategy is selected depending on whether it is present in a safe statement and type of statement of the AO.

1) Unchecked statement strategy

[0048] The system 100 is configured to apply the Unchecked statement strategy to safe statements. As per the strategy, safe statements are enclosed inside unchecked blocks without making any changes to the statements.
[0049] Two example approaches to apply this unchecked statement strategy are: 1) Adding each statement in a separate unchecked block (separate block approach), 2) Combining multiple safe statements together (common block approach).
[0050] In the separate block approach, each of the safe statements present in the same block is added in a separate unchecked block. If a safe statement that is child of a safe statement already added to unchecked block, adding the child statement in unchecked block is not required.
[0051] In the common block approach, as many safe statements as possible are enclosed together inside an unchecked block. With the approach, safe statements and no-POI statements that are consecutive and appearing inside a block can be enclosed together.
[0052] Note that in all the code examples discussed henceforth to illustrate the repair methodology, assumption made is that data types of all the variables and expressions in the shown code is “uint”/“uint256”, and only the code relevant for the discussion is shown. Further, in all the code examples, for discussion purpose, a few AOs are shown to be classified as safe and they are denoted using “safe AO” in the comment on the same line, and the AOs that are shown to be classified as error or alarm are denoted using “unsafe AO” in the comment added on the same line.

1.1 Repair of AOs using separate block approach and common block approach

[0053] Two (or more) consecutive safe statements shown in the original code in Table. 6 (lines 3 and 4) can be added separately inside unchecked blocks (as shown in the repaired code 1) as per the separate block approach and, they can be added together inside a single unchecked block (shown in the repaired code 2) as per the common block approach. In the example, common block approach generally is preferred because fewer code changes are made as compared to the separate block approach and the resulting code is more readable. However, for such cases, the system 100 can be configured to use separate block approach instead of the common block approach.
Original code showing two consecutive safe statements 1. function foo(){
2. for (uint j = 0; j < cnt; j++) { // unsafe AO (j++)
3. p++; // safe AO
4. q++; // safe AO
5. }
6. }
Repaired code 1 (using separate block approach) 1. function foo(){
2. for (uint j = 0; j < cnt; j++) { // unsafe AO (j++)
3. unchecked{
4. p++; // safe AO
5. }
6. unchecked{
7. q++; // safe AO
8. }
9. }
10. }
Repaired code 2
(using common block approach) 1. function foo(){
2. for (uint j = 0; j < cnt; j++) { // unsafe AO (j++)
3. unchecked{
4. p++; // safe AO
5. q++; // safe AO
6. }
7. }
8. }

Table. 6

1.2 Repair of AOs present in the top-level statements using top-down approach

[0054] Consider the original code shown in Table. 7, that has all AOs safe. To minimize the number of unchecked blocks to be added during the source code transformation, a top-down approach is adopted while applying unchecked statement strategy.
[0055] That is, starting from the function’s body (block statement) to its child statements, the statements that are to be enclosed inside unchecked block are identified.
[0056] In this example, since all AOs are safe, only one unchecked block is added enclosing the top-level statement inside unchecked block as shown in the repaired code.

Original code Repaired code
9. function foo(){
10. for (uint j = 0; j < cnt; j++) { // safe AO (j++)
11. p++; // safe AO
12. q++; // safe AO
13. } 14. } 1. function foo(){
2. unchecked{
3. for (uint j = 0; j < cnt; j++) { // safe AO (j++)
4. p++; // safe AO
5. q++; // safe AO
6. }
7. } 8. }

Table. 7

1.3 Repair of AOs by including in between no-POI statements and (avoiding no-POI statements at the start and end of the unchecked blocks)
[0057] This approach is used with an aim of reducing the number of unchecked blocks so that minimum changes are made, and the code is more readable. This is achieved by adding multiple consecutive safe and no-POI statements inside a single unchecked block. This is explained using the below example.
[0058] Consider the original code shown in Table. 8. The statements on lines 3 and 5 are safe, whereas the statements (on lines 2, 4, and 6 are no-POI statements). While using common block approach in top-down manner, it was identified that the block corresponding to the function’s body is to be unchecked. However, to make the repaired code more relevant and easier to read, only the safe statements that have safe AOs (lines 3 and 5) along with the in between no-POI statement (line 4) are included inside unchecked block, and the first and last no-POI statements in the shown function (lines 2 and 6) are not included inside the unchecked block.

Original code Repaired code
1. function foo(){
2. x = 0;
3. p++; // safe AO
4. t = 2;
5. q++; // safe AO
6. y = 3;
7. } 1. function foo(){
2. x = 0;
3. unchecked{
4. p++; // safe AO
5. t = 2;
6. q++; // safe AO
7. }
8. y = 3;
9. }

Table. 8

1.4 1.4: Repair of AOs present inside variable-declaring safe statements

[0059] For safe assignment statements that also declare a variable, if required the declaration is moved outside of the unchecked if any further use of the declared remains outside of the unchecked block being created. For instance, in Example 1 in Table. 9, safe statement on line 3 also declares “value”. Since this statement cannot be combined with any other safe statement, it is only the statement to be enclosed inside an unchecked block. If this statement is included inside an unchecked block, the same variable also being used (read) later on line 6, the program/code will not get compiled, i.e., there will be a compilation error. To avoid the compilation error, the declaration of value is taken outside of the unchecked block as shown in the corresponding repaired code. Example 2 shows such change in the declaration of the variable is not required if the statement on line 5 is safe, because the usage/read of the declared variable is also present in the same scope created by the unchecked block that encloses the variable declaring statement. Handling the declarations of variables by safe statements needs to be handled irrespective of the separate blocks approach or common block approach is used. Thus, applying this strategy for declared variables in a safe statement “s” also depends on the program safe and no-POI statements present before and after the statement “s”.

Original code Repaired code
Example 1 1. function foo(){
2. t = 0;
3. uint value = x + y; // safe AO
4. t = 2;
5. x = value + 2; // unsafe AO
6. } 1. function foo(){
2. t = 0;
3. uint value;
4. unchecked {
5. value = x + y; // safe AO
6. }
7. t = 2;
8. x = value + 2; // unsafe AO
9. }
Example 2 1. function foo(){
2. t = 0;
3. uint value = x + y; // safe AO
4. t = 2;
5. x = value + 2; // safe AO
6. }1. 1. function foo(){
2. t = 0;
3. uint value;
4. unchecked {
5. value = x + y; // safe AO
6. t = 2;
7. x = value + 2; // safe AO
8. }
9. }

Table. 9

2) Temporary variable strategy

[0060] The system 100 is configured to apply the temporary variable strategy when the unchecked statement strategy cannot be applied. In this strategy, a new temporary variable is created (i.e., a new variable is declared) where the datatype of the new variable is same as the datatype of the expression that denotes the safe AO for which repair is being performed. The temporary variable is then assigned with the values returned by the safe AO expression by creating a new assignment statement, and this assignment statement is enclosed inside an unchecked block. Next, the expression of the safe AO in the original location is replaced by the temporary variable created.

2.1 Temporary variable strategy for unsafe statements

[0061] Consider a safe AO is present in an unsafe assignment statement. To enclose a safe AO appearing on an unsafe statement inside an unchecked block, the temporary variable strategy is adopted. In such cases, the complete statement cannot be enclosed inside an unchecked block because otherwise the other AOs (at least one AO that is not classified as safe) in the same statement will get enclosed inside unchecked block and in such case the AO do not get checked at run-time by the EVM. In such case, an error scenario for that AO gets undetected at run-time and it can be exploited by attackers. The temporary variable strategy is applied in the following cases in which a safe AO can appear in an unsafe statement.

(1) safe AO is present in an unsafe assignment statement
(2) safe AO is present in the conditional expression of an if statement.
(3) safe AO is present in the conditional expression of an for/while statement.
(4) safe AO is present in the initialization expression of an unsafe for loop

[0062] The cases (2), (3), and (4) arise because AOs present in conditional expressions (of if statement and loop statements) and initialization and increment expressions of for/while loop statements cannot be directly enclosed inside an unchecked block if the corresponding top level statement is unsafe if/for/while statement. Furthermore, only complete statements can be included inside an unchecked block, and not the expressions unless they it is the top-level expression in an expression statement. Furthermore, to improve readability of the repaired code, the temporary variable strategy is applied if the corresponding if/for/while statement is safe and the number of safe AOs in the statement is less than some configured value.

2.1.1 Repair of safe AO is present in an unsafe assignment statement

[0063] Consider a safe AO “x + y” present in an unsafe assignment statement, e.g., the statement shown on line 4 in the original code in Table. 10. If the assignment statement is enclosed inside an unchecked block, the other AO (a + b) that is unsafe also gets enclosed in the same unchecked block. As a result, the EVM does not check this unsafe AO at runtime and does not detect the OFUF error if it occurs at run-time corresponding to this unsafe AO, and thus, the repair is not safe. Therefore, to perform repair corresponding to this safe AO, as shown in the repaired code, a new temporary variable is created (line 3), the result of the safe AO is captured in the same temporary variable inside an unchecked block (lines 4, 5, and 6), and the temporary variable is used in place of the original AO (line 8).
Original code 1. function foo(){
2. t = 0;
3.
4. uint value = (x + y) / (a + b); // AO x + y is safe, and a + b is unsafe
5. …
6. }
Repaired code as per temporary variable strategy 1. function foo(){
2. t = 0;
3. uint temp_var;
4. unchecked{
5. temp_var = x + y;
6. }
7.
8. uint value = temp_var / (a + b); // AO a + b is unsafe
9. …
10. }

Table. 10

2.1.2 Repair of safe AO present in conditional expression of an unsafe if statement

[0064] AOs present in the conditional expressions of an unsafe if statement are repaired using temporary variable strategy as shown with “Repaired code 1” in the following example in Table. 11. The complete if statement cannot be enclosed inside an unchecked block using top-down approach or separate block approach because the AO on line 4 is unsafe. Therefore, for this example, temporary variable strategy is followed. If the AO on line 4 is safe, the repair will be performed using unchecked statement strategy (top down approach and separate block approach) as shown with “Repaired code 2” in the following example. The two examples indicate that selecting a strategy for repairing a safe AO not only depends on the type of the statement, but also presence or absence of other safe and unsafe AOs in the statement of the safe AO as well in the code surrounding to the statement of the safe AO. The code surrounding to an safe AO can be identified based on one or more criteria like the statements that are in the same block of the safe AO’s statement, a code slice generated for the safe AO, the statements appearing before and after the safe AO’s statement, and the statements that are included in the safe AO’s statement if the AO’s statement is compound statement like if/for/while statement.
Original code 1. function foo(){
2. t = 0;
3. if( x + y > 0) // safe AO
4. x = x + 2; // unsafe AO
5. }
Repaired code1 as per temporary variable strategy 1. function foo(){
2. t = 0;
3. uint temp_var;
4. unchecked{
5. temp_var = x + y;
6. }
7.
8. if( temp_var > 0)
9. x = x + 2; // unsafe AO
10. }
Repaired Code 2 as per unchecked statement strategy (top-down approach) when “x+2” on line 4 is safe AO 1. function foo(){
2. t = 0;
3. unchecked{
4. if( x + y > 0) // safe AO
5. x = x + 2; // safe AO
6. }7. }

Table. 11

2.1.3 Repair of safe AO present in conditional expression of an unsafe for/while statement

[0065] A safe AO present in the conditional expression of an unsafe for and while statement is repaired only if none of the variables used in the AO expression is modified inside the body of the loop. If the AO expression is modified inside the loop’s body, the repair is not safe: an OFUF error may go undetected at run-time. Therefore, repairing of AOs in such cases requires computing whether the variables used in expression are modified inside the loop’s body.
[0066] Consider the example as shown in Table. 12. In the original code example, expressions p + q and a + b on line 2 are safe AOs, and both the AOs are present in conditional expression of the for statement. The ‘for statement’ is unsafe because the AO on line 3 is unsafe, and thus the complete for statement cannot be enclosed inside an unchecked block. In this case, the safe AO “p + q” is repaired by applying the temporary variable strategy, and the repaired code is as shown Table. 12. Here, enclosing the newly created assignment statement inside unchecked block is before the start of the loop statement. In the same example, the other safe AO “a + b” wasn’t repaired by the system 100, because one of the variables used in it, a, is modified inside the loop’s body at line 5. This example shows that the safe AOs present in the conditional expression of if statement and for statement are repaired by following different methods depending on the type of the statement in which the AO appears as shown in the Table 11 and Table 12 respectively.
Original code 1. function _foo(){
2. for(i = 0; i < p + q && i > a + b; i++) { // p + q, a+b are safe AOs, and i++ is unsafe AO
3. t = t + a; // unsafe AO
4. if(p == 2) {
5. a = 5;
6. }
7. }8. }
Repaired code as per temporary variable strategy 1. function _foo(){
2. uint temp_var;
3. unchecked {
4. temp_var = p + q;
5. }
6.
7. for(i = 0; i < temp_var && i > a + b; i++) {
8. t = t + a; // unsafe AO
9. if(p == 2) {
10. a = 5;
11. }
12. }13. }

Table. 12

2.1.4 Repair of safe AO present in initialization expression of an unsafe for statement

[0067] Safe AOs present in the initialization expression of an unsafe for statement is repaired using temporary variable method. A temporary variable is created and the safe AO present in the initialization expression is assigned to the temporary variable before the for statement. The assignment of temporary variable is enclosed in an unchecked block, and the AO in the initialization expression is replaced with the temporary variable created.
[0068] Following examples in Table. 13 show repair of a safe AO present in the initialization expression of an unsafe for loop.
Original code 1. function _foo() {
2. for(i = a + b; i < 100; i++) { //a + b and i++ are safe AOs
3. r = r * p; // unsafe AO
4. }5. }
Repaired code as per temporary variable strategy 1. function _foo() {
2. uint256 temp_var;
3. unchecked {
4. temp_var = – a + b;
5. }
6. for(i = temp_var; i < 100; i++) { //a + b and i++ are safe AOs
7. r = r * p; // unsafe AO
8. }6. }

Table. 13

2.2) Temporary variable strategy for a safe AO present in conditional expression of a safe if/for/while statements and initialization expression of a safe for statement

[0069] As an exception to the unchecked statement strategy, the temporary variable strategy is applied while repairing a safe AO present in (1) a conditional expression present in a safe if/for/while statement; and (2) initialization expression of a safe for statement. This is to improve readability of the repaired code and to make changes where they are relevant. For such safe statements (except safe assignment statements), the temporary variable strategy is applied if the total number of safe AOs present in non-assignment statement is less than a configured value. Consider the example in Table. 14 below. In this example, the if statement on line 2 has two safe AOs: “a + b” on line 2, and “200 + a” on line 10. Since this statement is safe, unchecked block strategy can be applied, making only one change to include the complete statement inside a single unchecked block. This reduces the number of changes. However, the downside of following this approach is that all other code that does not have AOs also gets added inside the same unchecked block. If the user/developer makes changes to such code, e.g., changing x = 20 on line 4 to “x = 20 + a + t”, two more AOs get added. These two new AOs are inside the unchecked block and the error if any goes undetected at run-time. Therefore, to avoid such side-effects of enclosing safe AOs inside unchecked blocks, the unchecked block strategy is over-ridden by using the temporary variable strategy. This override is decided based on the number of safe AOs present in the safe statement. If this number is less than or equal to configured threshold value, the system 100 applies the temporary variable strategy, otherwise unchecked block strategy gets applied. In the below example, the repairing performed is depicted when the configured threshold is 1 and 2.
Original code 1. function foo(){
2. if( (a + b) < 100;) { // a+b is safe AO
3. if(i ==10) {
4. x = 20;
5. continue;
6. }
7. if(x == 0)
8. r = foo();
9. else
10. t = 200 + a; // safe AO
11. emit(a, b, c);
12. }13. }
Repaired code with the configured value = 2 1. function foo(){
2. uint temp_var;
3. unchecked {
4. temp_var1 = a + b;
5. }
6. if( temp_var1 < 100;) { // a+b is safe AO
7. if(i ==10) {
8. continue;
9. }
10. if(x == 0)
11. r = foo();
12. Else {
13. unchecked {
14. t = 200 + a; // safe AO
15. }
16. }
17. emit(a, b, c);
18. }19. }
Repaired code with the configured value = 1 1. function foo(){
2. unchecked {
3. if( (a + b) < 100;) { // a+b is safe AO
4. if(i ==10) {
5. x = 20;
6. continue;
7. }
8. if(x == 0)
9. r = foo();
10. else
11. t = 200 + a; // safe AO
12. emit(a, b, c);
13. }
14. } 15. }

Table. 14

3) Code movement strategy

[0070] AOs present in an increment expression of an unsafe for statement are repaired by moving the increment expression to the end of each path that goes through the loop’s body and ends at the condition expression of the loop. As shown in the following example in Table. 15, there are two such paths; (1) the path that the statement on line 6 as its last statement, and (2) the path due to continue. The safe AOs present in the increment expression of the loop are moved to these locations. The resulting repaired code is shown under “repaired code”.
Original code 1. function foo(){
2. for(uint i = 0; i < q; i++) { // i++ is safe AO
3. if(i ==10) {
4. continue;
5. }
6. r = r * p; // r * p is unsafe
7. }8. }
Repaired code as per code movement strategy 1. function foo(){
2. for(uint i = 0; i < q; i++) { // i++ is safe AO
3. if(i ==10) {
4. unchecked {
5. i++;
6. }
7. continue;
8. }
9. r = r * p; // r * p is unsafe
10. unchecked {
11. i++;
12. }
13. }
14. }
Table. 15

[0071] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[0072] The embodiments of present disclosure herein address unresolved problem of reducing gas consumption in Ethereum smart contracts execution. The embodiment thus provides a mechanism to classify AOs as safe AOs, errors, or alarms. Moreover, the embodiments herein further provide a mechanism to perform an automated source code transformation to include the safe AOs inside unchecked blocks, to avoid checking of the safe AOs at run-time by an EVM, thereby reducing the gas consumption. The strategies used to automatically repair the source code are discussed using examples and are not limited to these examples. A strategy from the available strategies is selected for repairing a safe AO based on the several factors listed next but not limited to 1) the type of the AO, 2) the types of the statement and expression in which the AO appears, and 3) the code surrounding to the AO, i.e., the code appearing before and after the safe AO, 4) presence/absence of other safe and unsafe AOs in the same statement and expression of the safe AO, 5) presence/absence of the other safe AOs in the code surrounding to the safe AO. A plurality of conditions in terms of one or more of the aforementioned parameters (and any additional parameters) is configured with the system 100, such that a strategy to selected and used corresponding to each of the conditions also is defined. The system 100 processes the source code to determine if any of the defined conditions match the source code, and accordingly picks a corresponding strategy for source code correction. Various such conditions being checked by the system 100 are covered in explanation of the example strategies above.
[0073] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g., any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g., hardware means like e.g., an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g., an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g., using a plurality of CPUs.
[0074] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[0075] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[0076] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[0077] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.

, Claims::
1. A processor implemented method (200) of reducing gas consumption in an Ethereum smart contract, comprising:
obtaining (202), via one or more hardware processors, a source code as input;
identifying (204), via the one or more hardware processors, a plurality of arithmetic operations (AOs) in the source code;
classifying (206), via the one or more hardware processors, each of the plurality of AOs as a safe AO, an error, or an alarm, by processing the source code using one or more code analysis techniques; and
performing (208), via the one or more hardware processors, an automated source code transformation to include the safe AOs inside unchecked blocks in the source code, wherein the safe AOs included inside the unchecked blocks are not checked for an arithmetic overflow error detection and an arithmetic underflow error detection by an Ethereum Virtual Machine (EVM) at runtime, reducing gas consumption during execution of transactions of the Ethereum smart contract.

2. The method as claimed in claim 1, wherein processing the source code using the one or more code analysis techniques comprises:

obtaining (302) an initial classification of each of the AOs as being one of the safe AO, the error, or the alarm, wherein the initial classification is obtained by processing the plurality of AOs using at least one static code analysis technique from a first set of code analysis techniques from among the one or more code analysis techniques; and
processing (304) each of the AOs classified as the alarm in the initial classification, by performing an infeasibility analysis, comprising determining if each of the AOs classified as the alarm appears in one of a plurality of code patterns present in a reference code patterns set, wherein each of the AOs appearing in one of the plurality of code patterns present in the reference code patterns is re-labelled as the safe AO.

3. The method as claimed in claim 1, wherein performing the automated source code transformation based on the safe AOs comprises:
generating (402) one or more code repair instructions corresponding to each of the safe AOs, wherein the one or more code repair instructions specify code changes required to include each of the safe AOs inside the unchecked blocks, wherein the one or more code repair instructions are generated using one or more strategies from a set of predefined and configurable strategies for code repair, wherein the one or more strategies are selected based on a type of the statement of a code surrounding the safe AO, and presence or absence of one or more other safe and unsafe AOs in the code surrounding the safe AO; and
modifying (404) the source code based on the generated one or more code repair instructions to generate an output source code.

4. The method as claimed in claim 3, wherein the set of predefined and configurable strategies comprises a top down strategy, a bottom-up strategy, a temporary-variable strategy, an unchecked statement strategy, a code movement strategy, and a configuration-based strategy, to minimize code changes and improve readability of the output source code.

5. A system (100) for reducing gas consumption in an Ethereum smart contract, comprising:

one or more hardware processors (102);
a communication interface (112); and
a memory (104) storing a plurality of instructions, wherein the plurality of instructions when executed, cause the one or more hardware processors to:
obtain a source code as input;
identify a plurality of arithmetic operations (AOs) in the source code;
classify each of the plurality of AOs as a safe AO, an error, or an alarm, by processing the source code using one or more code analysis techniques; and
perform an automated source code transformation to include the safe AOs inside unchecked blocks in the source code, wherein the safe AOs included inside the unchecked blocks are not checked for an arithmetic overflow error detection and an arithmetic underflow error detection by an Ethereum Virtual Machine (EVM) at runtime, reducing gas consumption during execution of transactions of the Ethereum smart contract.

6. The system as claimed in claim 5, wherein the one or more hardware processors are configured to process the source code using one or more code analysis techniques, by:
obtaining an initial classification of each of the AOs as being one of the safe AO, the error, or the alarm, wherein the initial classification is obtained by processing the plurality of AOs using at least one static code analysis technique from a first set of code analysis techniques from among the one or more code analysis techniques; and
processing each of the AOs classified as the alarm in the initial classification, by performing an infeasibility analysis, comprising determining if each of the AOs classified as the alarm appears in one of a plurality of code patterns present in a reference code patterns set, wherein each of the AOs appearing in one of the plurality of code patterns present in the reference code patterns is re-labelled as the safe AO.

7. The system as claimed in claim 5, wherein the one or more hardware processors are configured to perform the automated source code transformation based on the safe AOs, by:
generating one or more code repair instructions corresponding to each of the safe AOs, wherein the one or more code repair instructions specify code changes required to include each of the safe AOs inside the unchecked blocks, wherein the one or more code repair instructions are generated using one or more strategies from a set of predefined and configurable strategies for code repair, wherein the one or more strategies are selected based on a type of the statement of a code surrounding the safe AO, and presence or absence of one or more other safe and unsafe AOs in the code surrounding the safe AO; and
modifying the source code based on the generated one or more code repair instructions to generate an output source code.

8. The system as claimed in claim 7, wherein the set of predefined and configurable strategies comprises a top down strategy, a bottom-up strategy, a temporary-variable strategy, an unchecked statement strategy, a code movement strategy, and a configuration-based strategy, to minimize code changes and improve readability of the output source code.