Finalidad y Objetivos de la Investigación 1 Finalidad

The second biggest cryptocurrency is Ethereum, which was proposed in 2014 by Vitalik Buterin [37] and later formalized [186] and implemented. The design of Ethereum differs from Bitcoin in some ways but the most important one is that it provides rich scripting features and smart contracts. It enables countless novel

applications and is often regarded as a glimpse into our future.

3.2.1 Smart Contracts

Informally speaking, smart contracts are coded agreements, which are stored on the blockchain, that can receive, store, and redistribute coins depending on some well- specified conditions. Smart contracts bind money transfers to program code, and thereby allow to execute transactions based on complex contractual agreements enforced by the miners of the cryptocurrency. Unlike Bitcoin, Ethereum does not work in the UTXO model but in an account-based model, which distinguishes two types of accounts:

Externally owned accounts Represented though a public address, based on an ECDSA public key, these accounts are controlled by users. Sending coins requires a correctly signed transaction.

Contract accounts These accounts are controlled by their contract code, which describes how stored coins are redistributed. Contract addresses are gener- ated during deployment.

Every account is identified over an address and can hold Ether (the currency unit in Ethereum). Contract accounts additionally also store their contract code (in bytecode form) and storage. Once deployed, the contract is public and all users may interact with it. A smart contract cannot act on its own. Instead, it needs to be triggered by a transaction from an externally owned account. Such a contract function call contains the function parameters and might optionally contain funds that are sent to the smart contract. Such a transaction is executed by the miners that evaluate the contract function code with the provided parameters as input. As a result, the contract state is updated. All honest miners verify the correctness

of published blocks and, thus, also of the state updates. All miners must have the same view on the code and execution of contracts. Thus they can only run deterministic code and cannot have a private state.

Smart contracts are passive pieces of code that do not act on their own nor interact with users directly. Therefore, we require that whenever a contract func- tion needs to be evaluated, a user triggers the contract with a function call. If one contract is activated from an externally owned account, it can also call other contracts via their address. A call from one contract CA to another contract CB is called a contract message. They work similarly to contract calls and reference a specific function. Contract messages can contain function parameters and even transfer coins. After the function evaluation in contractCB finishes, the rest of the contract CA is executed.

Miners locally store the state of the Ethereum system, which contains the current state of all active contracts. Ethereum blocks contain both the list of transactions and a hash of the most recent state. This allows Ethereum nodes to execute contract calls quickly and verify the state transition proposed by new blocks. Contract Deployment

In Ethereum, smart contracts can be written in a scripting language (e.g., Solid- ity), which is then compiled down to low-level Ethereum Virtual Machine (EVM) bytecode. In order to deploy a contract, an externally owned account publishes a createtransaction, which includes the contract code as storage. When this trans- action is processed, the contract code will be written on the blockchain, and a contract address is generated. If the contract contains a constructor, this function is executed immediately by the miners.

A recently added EVM instruction3 _{introduced a new way of contract deploy-}

ment [80]. Previously, a contract address is generated during deployment, and it was not possible to securely predict which address this would be. The newcreate2 transaction deterministically calculates the address from the hash of the contract code instead. This method allows users to reference and send coins to contracts that do not exist yet. The secure binding of code and address guarantees that they can always deploy the code later, if necessary.

Ethereum Gas Model

Transaction fees for Ethereum transactions are paid in gas, which is an internal

Ethereum currency. Transaction fees in Ethereum are essential to prevent Denial of Service (DoS) attacks, which could force all miners to run unnecessary long code and block their verification resources. Therefore, the amount of gas depends on the size and complexity of transactions. The exact gas value is measured by accumulating the costs of every EVM instruction in the code. All instructions in Ethereum have a fixed amount of gas assigned to it [186]. If a transaction does not contain a sufficient amount of gas, the miners stop the contract execution and revert all changes to the state. Additionally, to the gas amount, every transaction also specifies a gas price, which defines the exchange rate between gas and ether. As miners will always consider transactions with the highest revenue first, the gas price influences how fast a transaction will be processed. Just as in Bitcoin, these transaction fees underly the market demand and rise when blocks get full. In Ethereum, the block size is bounded by how much gas can be used for evaluating all transactions inside it. Table 3.2 shows the relation of gas prices to the confirmation times. For this thesis, we will consider a medium priority of transactions, which means all transaction costs are computed with a gas price of 3 Gwei. We chose this value because it leads to approximately one minute of confirmation time, which still means the protocols will proceed reasonably fast (especially compared to Bitcoin). At the same time, the gas prices are low enough to be comparable with related works. For all calculations in this thesis, we choose an exchange rate of 162.43 euros per Ether, which corresponds to the 180 day average exchange rate calculated on the 24th of February 2020. The data was taken from etherscan.io [78].

Priority Gas Price Waiting Time # of Blocks

low 1 GWei 3640.666667 sec 317.6

medium 3 GWei 326.3333333 sec 27.35

high 6 GWei 37.66666667 sec 2.45

very high 12 GWei 24.66666667 sec 2

Table 3.2: Average time and number of blocks that it takes until an Ethereum transaction is processed.

The price per instruction varies largely, where the overall idea is that instruc- tions that require a lot of the miner’s resources are more expensive. For instance, addition costs 3 gas and multiplication, or modulo operations require 5 gas. Some

cryptographic operations like signing and hashing have their own instructions in the EVM language, i.e., evaluating the Keccak-256hash on a 32 byte input takes 36 gas. Storage is especially expensive in Ethereum since every stored value takes space in the state, which all miners have to store in highly accessible memory. Storing a 32 byte word to the Ethereum storage costs 20000 gas and 5000 if al- ready allocated storage is reused. Storing values to volatile memory instead is much cheaper and only requires 3 gas units. A special EVM instruction called selfdestruct allows users to deactivate contracts, such that they can be excluded from the miner’s state. This instruction can even lead to the payout of gas to the users.

3.2.2 Designing Secure Contracts

An essential component for the construction of secure smart contracts is the con- cept oftimeouts. Whenever an input of a party is required, we construct a timeout

around the expected message, which is large enough that an honest party always has sufficient time to react. If an expected message is not received in time, we consider this a faulty behavior. The other contract participant(s) can then trigger a timeout function, which verifies the misbehavior and punishes the party for the missing input. For the secure design of smart contracts, it is crucial that honest parties must never be punished, and therefore, the timeout is sufficiently large. In this thesis, we denote this maximal waiting time as the blockchain delay ∆. We note that in most cases, parties will react reasonably fast, but an honest party’s response could nevertheless be delayed up to ∆ rounds (but not longer). Addition- ally, we require that every transaction and state change is only considered valid, after it has been confirmed by a few more blocks. This security measure mitigates the risks of temporary forks.

When designing secure smart contracts, we always try to identify malicious be- havior. Fault attribution is necessary whenever the contract ends up in a state which does not happen during honest behavior. We distinguish between uniquely

and non-uniquely attributable faults. Uniquely attributable faults occur when a

malicious party does not follow the protocol, and the other participants can con- vince the contract about this fact. This case occurs, e.g., when a party signed two contradictory statements, or when a timeout expires. A fault is non-uniquely attributable if some participant of the protocol knows that some other party is dishonest, but they are not able to prove it to the contract. A standard example is a situation when a message is sent directly from a party P to partyQ. In this

case,Qmight claim that the message was not received whileP claims that he sent it. The parties know who of them is dishonest, but neither can prove it. Uniquely attributable faults are easy to handle since we can instruct the contract to punish the cheating party financially. Non-uniquely attributable faults are harder to deal with as it is not clear who should be punished and which party is telling the truth. Grieving. Another factor that needs to be considered for a secure and fair con- tract design is how much fees each party needs to pay. Ideally, the fee burden is equally distributed over all protocol participants, and the maximum amount of fees can be predicted before the protocol starts. This is often not possible when one of the parties misbehaves. In these cases, it would be ideal if the faulty party can be identified and has to carry the fees.

If one of the parties can force another party to pay a much higher share of the fees, we call this a grieving attack. More precisely, a grieving factor of 2 : 1 means that it costs roughlyxcoins to force another party to pay 2xcoins in fees. Ideally,

the factor is 1 : 1, such that no party has an advantage, or even better, every fault can be attributed, and the misbehaving party carries all fees.

Grieving can also be applied to coin deposits or so-called collateral [74]. For

the security of some smart contracts, parties need to lock coins for a certain time, e.g., penalty deposits or locking coins for routing payments in payment channels (cf. Section 3.3). For the duration of this locked deposit, the owner cannot use the coins for any other purpose, and the opportunity costs are often regarded as collateral costs. Grieving occurs in this case as well, when a malicious party

forcibly prolongs the duration of deposits, which increase costs for honest parties. In particular, smart contracts need to ensure that any locked deposit is unlocked eventually, and the lock time is upper bounded.