Workshop 4D:

Smart Contract
Security
Richard Liu and Max Fang
Blockchain at Berkeley

Smart Contract Programming: Differences

Differences between smart contract programming and traditional programming

● Real money at stake
○ Typical scenario: exploit gains access to data
○ In blockchain, actual money involved in contracts

Therefore, distributed currencies and platforms are the most adversarial environment
● Unfortunately, designing simple contracts is very non-trivial
● Even a Rock-Paper-Scissors contract is highly non-trivial

Why don't we implement smart contracts on Bitcoin?

● Bitcoin scripting language is unwieldly
○ Stack-based programming language based on Forth
● Attempts to retrofit to Bitcoin's Scripting language are still expensive
○ Asymptotically higher on-chain cost
○ Ex. Bitcoin script doesn't support loops, so have to unroll the entire loop

blockchain.berkeley.edu 2 | October 2016

Blockchain at Berkeley

Platform Recap

Ethereum Contracts can call other contracts

● Execution of smart contract code in ● Often, getting real world data is calling
lockstep by nodes on the network another smart contract
● Each contract has code and data storage ● Ex. Bloomberg contract
○ The platform itself manages consensus on
the network state Gas
● Making transactions requires gas
Smart contracts as replacement for the ○ Gas is deducted no matter if function call
"trusted third party" finishes or not
● Trust that code runs correctly ● Gas mechanics between contract calls
● Trust that contract is always available to call ○ Default behavior: send all the gas
● But not for privacy available
○ Optionally specify a portion of gas you
Smart contracts as 'autonomous entities' want to send
● Defined set of functions that you may call
○ Runs code when 'poked' by a transaction

blockchain.berkeley.edu 3 | October 2016

Blockchain at Berkeley

Mistakes to Avoid

● Blockchain is a state machine

○ Programming these is tricky

blockchain.berkeley.edu 4 | October 2016

Blockchain at Berkeley

Mistakes to Avoid: Challenges

1 - Unexpected Behavior
● Examine player_input
○ msg.value != 1000
○ Player 3 joins game
● Both lose money!
○ Money from inputs should be
refunded

blockchain.berkeley.edu 5 | October 2016

Blockchain at Berkeley

Mistakes to Avoid: Challenges

2 - Dishonest Individuals
● Player choices sent in plaintext
● Cheating player can peek
○ Always pick winning option
○ Game theory:
■ Anonymous system
● no reputation
■ Goal: maximize financial gain

blockchain.berkeley.edu 6 | October 2016

Blockchain at Berkeley

Mistakes to Avoid: Solutions

Solution: Cryptography
● Hash functions:
○ binding - “second-preimage resistant”
○ hiding - “preimage resistant”

● Opponent cannot deduce message

● Sender cannot modify message
● Non-malleable

blockchain.berkeley.edu 7 | October 2016

Blockchain at Berkeley

Hashing Review
* k
We define a cryptographic hash function: H : {0,1} ⟼ {0,1}

Maps some arbitrarily-sized bit string to some fixed-size bit string.

The function is deterministic; the same input always yields the same output.

“The workhorses of modern cryptography” - Bruce Schneier

Example: SHA256 maps to a 256-bit string

> echo “Hello, world!” | sha256sum

0xd9014c4624844aa5bac314773d6b689ad467fa4e1d1a50a1b8a99d5a95f72ff5

blockchain.berkeley.edu 8 | October 2016

Blockchain at Berkeley

Properties of a Cryptographic Hash Function

Notation: red is hidden, blue is public

Preimage Resistance:
*
Let x = {0,1} = message

y = H(x)
-1
x = H (y) → should be computationally difficult

+ It should be extremely difficult to find the preimage (original value) of a

hash output.

blockchain.berkeley.edu 9 | October 2016

Blockchain at Berkeley

Properties of a Cryptographic Hash Function

Second Preimage Resistance:

Given message x

Finding some x’ s.t. H(x’) = H(x) should be computationally difficult.

blockchain.berkeley.edu 10 | October 2016

Blockchain at Berkeley

Properties of a Cryptographic Hash Function

Collision Resistance:

Suppose we have two messages x1, x2

The probability that their hashes are equal, P(H(x1) = H(x2)), should be “very
small”

Equivalently, finding x1, x2 such that H(x1) = H(x2) should be

computationally difficult.

1/2
The upper bound to find a collision is at most O(N ) (called a Birthday Attack)

blockchain.berkeley.edu 11 | October 2016

Blockchain at Berkeley

Why are cryptographic hash functions useful?

In the context of Bitcoin and other Cryptocurrencies:

+ Merkle Trees
+ Proof-of-Work (Bitcoin, Litecoin, Dogecoin, etc…)
+ Transactions, Blocks, Addresses all referenced by hash value

Also

+ Fundamental operation in many cryptographic protocols

+ Hash-based Message Authentication Codes (HMACs)
+ Password Verification
+ Commitment Schemes
+ Pseudo-Random Number Generators (PRNGs)
blockchain.berkeley.edu 12 | October 2016
Blockchain at Berkeley

Mistakes to Avoid: Solutions

Solution: Cryptography
● Hash functions:
○ binding - “second-preimage resistant”
○ hiding - “preimage resistant”

● Opponent cannot deduce message

● Sender cannot modify message
● Non-malleable

blockchain.berkeley.edu 13 | October 2016

Blockchain at Berkeley

Mistakes to Avoid: Challenges

3 - Misaligned Incentives
● Commitments solve “peeking”
● Second player sees loss
○ Should be indifferent
○ Negative incentive to open commitment
■ Costs gas
○ Smart contract never pays out
■ Loser saves gas cost

blockchain.berkeley.edu 14 | October 2016

Blockchain at Berkeley

Mistakes to Avoid: Solutions

Realigning Incentives
● Construct contract carefully
○ Users are ALWAYS incentivized to cooperate
● Rock-Paper-Scissors
○ Solution: set deadline for reveal after 1st player
■ If 2nd player doesn’t reveal, 1st player wins
■ Include security deposit
● Forfeited if player chooses not to reveal

blockchain.berkeley.edu 15 | October 2016

Blockchain at Berkeley

Mistakes to Avoid: Ethereum-Specific

Call-Stack Depth
● Ethereum recursion stack: 1024 calls high
● What happens at depth 1025?
○ Nothing.
○ Literally nothing.
● Consider code to the right
○ Only goes 2 calls deep
○ Contract calling it may go deeper
● Payouts messed up:
○ Users miss out on send entirely
○ Sending money/gas to (buggy) contracts
■ Default behavior: send all gas
blockchain.berkeley.edu 16 | October 2016
Blockchain at Berkeley

Mistakes to Avoid: Ethereum-Specific Pitfalls

Example: Etherpot
● Ethereum-based lottery
○ Random value: hashes of (future) blocks
Blockhash Bug
● Problem: winner had to cash out fast
● block.prevhash supports 256 most recent
○ Within 256-block limit
blocks
○ Around 85 minutes
○ Intended to help efficiency
○ Proposed fix: “blockhash service”
■ Contract to retrieve block hashes
beyond 256

blockchain.berkeley.edu 17 | October 2016

Blockchain at Berkeley

Mistakes to Avoid: Ethereum-Specific Pitfalls

Example: Etherpot
● Ethereum-based lottery
○ Random value: hashes of (future) blocks

Ethereum-Specific Incentive Bugs

● Miner finds future block ● Solution: align incentives!

○ Oh no! Does not win ○ Lottery prize lower than block reward

● Miner withholds block ○ Withholding block: forgoes reward

○ Wait until another block found

■ Effectively gives miner second chance

blockchain.berkeley.edu 18 | October 2016

Blockchain at Berkeley

In Summary

Smart Contract One Unexpected Behavior

Two Cryptography
Security Three Align user incentives

blockchain.berkeley.edu 19 | October 2016

Blockchain at Berkeley

Mistakes to Avoid: Ethereum-Specific Pitfalls

Presentation based on
"Step by Step Towards Creating a Safe
Smart Contract: Lessons and Insights from
a Cryptocurrency Lab"

blockchain.berkeley.edu 20 | October 2016

Thanks!
We’re the world’s first university-based
blockchain consulting firm.

Like us on Facebook:
@Berkeleyblockchain
https://www.facebook.com/berkeleyblockchain/