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/
