https://blog.acolyer.org/2017/02/23/making-smart-contracts-smarter/

What’s a smart contract?

  • a 160-bit identifier, code is on blockchain
  • invoked by sending transactions to contract address
  • e.g. blockchain accepts transaction and if specified recipient is the contract address, then all participants on mining network execute contract code using inputs as current state of blockchain and transaction payloads. output is agreed upon by the network through consensus protocol.

Smart contracts in ETH

  • creation transactions = what contract introductions to the blockchain are called
  • contracts usually get written first with higher-level languages, and are compiled down to EVM bytecode
  • are stateful: have private storage (initialized by a constructor) on blockchain and can hold Ether
  • payments
  • miners are paid out fees proportional to required computation each instruction in EVM bytecode has pre-specified amount of gas when user sends transaction to invoke a contract, need to state how much gas they’re willing to pay (gasLimit) and price for each gas unit (gasPrice) miner who is executing transaction receives amount of gas actually burned * gasPrice if computation goes over gasLimit, miner still receives gasLimit but execution gets terminated
  • since it’s not possible to patch a buggy contract, it’s important to be able to reason through the correctness of a smart contract before it’s deployed

According to the paper, main vulnerabilities of smart contracts are:

  • transaction-ordering dependence
  • e.g. for the puzzle-solution contract, if someone comes in with solution hoping for reward, owner of contract can come in before reward is given after changing the reward size = owner gets solution without payout
  • timestamp dependence
  • mishandled exceptions
  • contracts can call each other, but exceptions in callee (contract being called) may not get propagated to the caller = bad exception handling
  • reentrancy vulnerability
  • when contract calls another, the execution is blocked by the call issue comes up when recipient of call uses the intermediate state of the caller

How to protect smart contracts

  • transaction ordering
  • should evaluate a guard clause (predicate) before transactions
  • timestamp dependency
  • don’t depend on timestamp
  • exception handling
  • check return values of each depth of call