Configuraciones Punto a Punto Ethernet Activa

Keeping the vulnerabilities and the total number of vulnerable smart contracts in mind, improving the security of smart contracts is important. ConsenSys Diligence

published a list of recommendations on their website, but developers are advised to consult multiple sources. The list as of May 25, 2017 is shown in Table 4.6.

TABLE 4.6: Security recommendations smart contracts (ConsenSys Diligence, 2018c)

Level Recommendation

Protocol

External Calls - Use caution when making external calls External Calls - Mark untrusted contracts

External Calls - Avoid state changes after external calls External Calls - Be aware of the trade-offs betweensend(),

transfer(), andcall.value()()

External Calls - Handle errors in external calls External Calls - Handle errors in external calls

Don’t assume contracts are created with zero balance Remember that on-chain data is public

In 2-party or N-party contracts, beware of the possibility that some participants may “drop offline” and not return

Solidity

Enforce invariants with assert()

Useassert()andrequire()properly Beware rounding with integer division

Remember that Ether can be forcibly sent to an account

Be aware of the trade-offs between abstract contracts and interfaces Keep fallback functions simple

Explicitly mark visibility in functions and state variables Lock pragmas to specific compiler version

Lock pragmas to specific compiler version - Exception Differentiate functions and events

Prefer newer Solidity constructs

Be aware that “Built-ins” can be shadowed Avoid usingtx.origin

Timestamp Dependence - Gameability Timestamp Dependence - 30-second Rule

Timestamp Dependence - Caution usingblock.numberas a timestamp Multiple Inheritance Caution

(Deprecated)- Beware division by zero (Solidity < 0.4)

The use of libraries and reuse of functions can be powerful for starting devel- opers. Consider the code example of Listing 4.3 based on the example described in the Solidity documentation (Ethereum Foundation, 2018d). To become the “rich- est”, one needs to send more Ether to the contract than the previous person did. However, when richest.transfer(msg.value); invokes a fallback function that throws an exception, the smart contract becomes inaccessible. In this case the use of

richest.transfer(msg.value);seems to be trivial but is actually dangerous. De- velopers are advised to reuse functions programmed by experienced developers or professional organisations to prevent these kinds of situations (Ethereum Founda- tion, 2018d).

Chapter 4. Smart Contract Vulnerabilities 34 1 f u n c t i o n b e c o m e R i c h e s t () p u b l i c p a y a b l e r e t u r n s (b o o l) { 2 if (msg.v a l u e > m o s t S e n t ) { 3 // T h i s l i n e can c a u s e p r o b l e m s 4 r i c h e s t .t r a n s f e r(msg.v a l u e) ; 5 r i c h e s t = msg.s e n d e r; 6 m o s t S e n t = msg.v a l u e; 7 r e t u r n tr u e; 8 } e l s e { 9 r e t u r n f a l s e; 10 } 11 }

LISTING 4.3: Vulnerable withdraw function (Ethereum

Foundation, 2018d)

To keep the risks as low as possible, smart contract developers are advised to use circuit breakers, speed bumps, rate limiting, updatable smart contracts, contract roll-out plans and bug bounty programs (ConsenSys Diligence, 2018d). The first four are controls that should be implemented in the architecture of the smart contracts, while the latter two are activities that should be performed after the initial design and development.

Circuit Breaker Implementing a circuit breaker allows the developer of a smart

contract to “pause” functions in their smart contract in case there is something wrong. In Solidity this can be implemented by creating a modifier that checks whether a spe- cific variable, such asbool private emergency, is set to true. This modifier can then be used in functions that should not be able to be called in case of emergency.

Speed Bumps A speed bump is a method to delay actions in a smart contract. For

example, it can only allow withdrawing the balance of a smart contract when there was no activity in the last 24 hours.

Rate Limiting Rate limiting is the practice of limiting significant changes in a smart

contract. For example, the owner is only allowed to withdraw 5% of the total balance per day. In case a dishonest person becomes the owner of the smart contract, he will not have the ability to withdraw the total balance. This gives the actual owner of the smart contract some time to start thinking about a solution.

Updatable smart contracts A smart contract, at least the EVM code, is immutable:

it cannot be changed in any way once the code is deployed on the blockchain. As pointed out in the problem statement of this thesis (section 1.2), the entities that use smart contracts need methods to update their smart contracts. ConsenSys Diligence briefly describes two approaches to allow this. The first approach is to create a smart contract that acts as a register. A user that wants to interact with the smart contract needs to look up the address of the most recent smart contract manually in the reg- ister. The second method presented by ConsenSys Diligence is to use a proxy smart contract to refer to the most recent version of the real smart contract.

Other Measures Next to the measures described above, smart contract developers

• Design patterns (Destefanis et al., 2018; Coplien, 1998)

• Best practices (Destefanis et al., 2018; Dika, 2017)

• Libraries (Ethereum Foundation, 2018d)

• Testing (Destefanis et al., 2018)

• Vulnerability scanners (section 4.2)

• External security audit (Dika, 2017)

• Development methodology (Destefanis et al., 2018)

• Formal verification (Abdellatif and Brousmiche, 2018; Mavridou and Laszka, 2018)

During this research, no specific information on the use of software development life cycles models smart contract development was found. Structured processes such as waterfall or agile oriented methods, might contribute to more secure smart contracts.

36

Chapter 5

Existing Solution Designs

Introduction

This chapter seeks to present an overview of existing solution designs and the asso- ciated limitations. These solution designs are identified from the literature studies conducted towards blockchain, smart contracts and smart contract vulnerabilities. The results of these literature studies suggest that smart contracts with an update ability are not a topic of academic research to this date, therefore, this study is re- quired to consult non-academic online sources. Additionally, this chapter provides insights into the update processes of blockchain protocols in order to gain a broader understanding of the challenges.

First, this chapter describes existing designs for smart contracts that have the ability to be updated, after which it elaborates on the update mechanisms of block- chain protocols.

5.1

Manual Register

In section 4.3, on recommendations for smart contract security, two approaches were briefly touched upon: a manual register and a proxy. The first approach, a manual register, requires a second smart contract that maintains a register with the address of the most recent smart contract with the core functionality ConsenSys Diligence (2018d). To use to the core smart contract, a user first needs to look up the address of the most recent core smart contract in the register smart contract. The user can then start interacting with the core smart contract using the found address. Figure 5.1 shows a visualisation of this approach.

Step 01: Lookup address

Step 02: execute transaction

Smart contract User Method call Return data User Register smart contract Call variable Return variable

Although the approach is straightforward, it has a number of major disadvan- tages. First of all, as stated by ConsenSys Diligence, this approach is not efficient as it requires users to perform an extra step. Not only does this lead to a decreasing user-friendliness but it also increases the chance of potential human errors as users need to copy and paste the address manually.

The second disadvantage of this update method is that it is vulnerable to a transaction-ordering dependence attack (section 4.1). Although this type of attack could happen for every transaction, this update method adds another level of un- certainty to it. Between the time that the user looked up the address of the current version of the smart contract and actually created a transaction to that smart con- tract, the register could be updated with a new version of the smart contract. As such, the users have less certainty about the actual version of the smart contract. The solution also does not provide information on how the update process should be implemented and executed by, presumably, the developers.

Third, the authors do not provide information on how the owners of a smart contract should migrate data and funds to new smart contracts. This could be a major challenge given that the migration should be supported by methods inside the smart contract that needs to be updated. Depending on the situation, the func- tionality might also need to support the migration when the data structures of the outdated and new smart contract differ.