Ethereum VM and DSLs for Smart Contracts (updated on May 12th 2015)

Ethereum VM &
DSLs for
Smart Contracts

$ whoami
Name: Zvi Avraham
Title: Founder & CEO
Company: ZADATA Ltd
Email: zvi@zadata.com

Agenda
• How Bitcoin works
• Bitcoin Script
• Intro to Smart Contracts
• What is Ethereum
• Ethereum VM
• DSLs for Smart Contracts

What is Bitcoin?
send X bitcoins
from address A
to address B

What is Bitcoin?
send X bitcoins
from address A
to address B
under condition C

“Under condition C”
• C – is a predicate that Tx is valid
• Q: How Bitcoin represents C?
• A: Using a pair of “Bitcoin Scripts”
– Locking script
– Unlocking (or redeem) script
ZΛDΛTΛ © 2015

What is Bitcoin Script?
• Forth-like, stack-based VM, RPN
• 1 byte opcodes
• All values are variable length byte
arrays
• Type interpreted by operations
• Only stack & alt-stack
• No return stack (no calls)
• No heap
• Deterministic - No side effects or I/O

RPN Calculators
• Infix:
2 + 3 =
• Postfix (RPN):
2 ↑ 3 +

http://neilk.net/blog/2015/02/14/hea
rtforth/
http://neilk.net/bloghttp://neilk.net/blog/2015/02/14/heartforth/

Why Stack-based VM?
• memory efficient
• easy to implement VM
– no need for a lexer, parser or AST
• Portable
– run on devices: phones or calculators
without consuming too much bandwidth
• compact code
– storage on the Bitcoin Blockchain is
very expensive ($600K/GB @ $220/BTC)

Compact Code
Register VM (3 operands)
MOV R1,#2
MOV R2,#3
ADD R3,R1,R2
MOV R1,#2
ADD R1,#3
Stack-based VMs (0 operands)
2
3
ADD
Register VM (2 operands)
Blockchain storage is very expensive ~ $600K/GB ($220/BTC)
≥ 6B
≥ 4B
≥ 3B

http://yosefk.com/blog/my-history-with-forth-stack-machines.html

Bitcoin Script Limitations
• deterministic, but not Turing complete
- intentionally
• no loops - disallow infinite loops
• no recursive functions
– no functions at all
• no jumps/goto
– but has (OP_IF,OP_ELSE,OP_ENDIF)
• many opcodes disabled (string ops)
• sigop counts – limit # of hashing ops
• scripts are limited in size - max 500B

1 Byte Opcodes
OP_0
OP_FALSE=OP_0
OP_PUSHDATA1
OP_PUSHDATA2
OP_PUSHDATA4
OP_1NEGATE
OP_RESERVED
OP_1
OP_TRUE=OP_1
...
OP_VER
OP_IF
OP_NOTIF
OP_VERIF
OP_VERNOTIF
OP_ELSE
OP_ENDIF
OP_VERIFY
OP_RETURN
...
OP_TOALTSTACK
OP_FROMALTSTACK
OP_2DROP
OP_2DUP
OP_3DUP
OP_2OVER
OP_2ROT
OP_2SWAP
OP_IFDUP
...
ZΛDΛTΛ © 2015

UTXO – Unspent Transaction Output

Tx Fees
• sum(TxInputs) ≥ sum(TxOutputs)
• TxFee = sum(TxInputs) – sum(TxOutputs)
• Min: 0.0001 BTC / 1000 bytes of tx (~ $0.022)
• fee goes to the miner who found a block,
which includes this tx

Blockchain – tree of Blocks
• Blocks (BlockHash 32B)
–Txs (TxId - reverse TxHash 32B)
• Inputs (#)
–reference to UTXO (TxId, output#)
–lock script (scriptPubKey)
• Outputs (#)
–value (in satoshis = BTC*10−8)
–unlock script (scriptSig)

• scriptSig / unlocking / input script - key icon
(input spending UTXO)
• scriptPubKey / locking / output script - lock
icon (output of UTXO)

• output(input) pair as an invocation
• output script - like a function (a hardcoded
function - tx type)
• input script - like a parameters to a function

Examples of Conditions
• AlwaysPay(_) = true
• NeverPay(_) = false
• HowMuchIs2by2(Answer) = (Answer == 2*2)
• CheckPwd(Password) = (Password==“secret”)

Examples of Conditions (2)
• P2PK(PubKey')(PubKey, TxSig) =
(PubKey' == PubKey) &&
checksig(PubKey, TxSig)
• P2PKH(PubKeyHash)(PubKey, TxSig) =
(PubKeyHash == ripmd160(PubKey))
&& checksig(PubKey, TxSig)

Evaluation Logic
1. Start with an empty stack
2. Evaluate the “unlock script”
(scriptSig) from UTXO
3. Evaluate the “lock script”
(scriptPubKey) from current
tx input
4. If result is true (1), tx is
valid, otherwise invalid

“Always Pay Anyone” ;)
Stack scriptSig scriptPubKey
… OP_TRUE
…
Concatenate both scripts & start with empty stack

… OP_TRUE
…
…
Don’t care what’s in scriptSig – unless it invalidate the
Tx. May even leave stuff on the stack.

… OP_TRUE
…
…
…

… OP_TRUE
…
1
…
…
The top of the stack is 1 (i.e. true) – the Tx is valid!

“Don’t Pay” – “Burn bitcoins”
… OP_FALSE
…

… OP_FALSE
…
…

… OP_FALSE
…
…
…

… OP_FALSE
…
0
…
…
The top of the stack is 0 (i.e. false) – the Tx is invalid!
These bitcoins are burned forever - unspendable!

Pay to math genius who knows
how much is 2 * 2 = ?
4 2
2
OP_MUL
OP_EQUALVERIFY

_4 2
2
OP_MUL
OP_EQUALVERIFY
4
Push constant to the stack

_4 2
2
OP_MUL
2 OP_EQUALVERIFY
4

_4 2
2
2 OP_MUL
2 OP_EQUALVERIFY
4

_4 2
2
OP_MUL
4 OP_EQUALVERIFY
4
Multiply 2 values on top of the stack

_4 2
2
OP_MUL
OP_EQUALVERIFY
4 == 4 – the Tx is valid!
Too easy – need a real cryptographic solution!

Pay to PubKeyHash - P2PKH
<sig> OP_DUP
<pubKey> OP_HASH160
<pubKeyHash>
OP_EQUALVERIFY
OP_CHECKSIG
Concatenate both scripts & start with empty stack.
99% of all Bitcoin Txs use this script.

<sig> OP_DUP
<pubKey> OP_HASH160
<pubKeyHash>
OP_EQUALVERIFY
<sig> OP_CHECKSIG
push constant onto the stack

<sig> OP_DUP
<pubKey> OP_HASH160
<pubKeyHash>
<pubKey> OP_EQUALVERIFY
<sig> OP_CHECKSIG

<sig> OP_DUP
<pubKey> OP_HASH160
<pubKey> <pubKeyHash>
<sig> OP_CHECKSIG
Duplicate value on the top of the stack

<sig> OP_DUP
<pubKey> OP_HASH160
<pubKeyHashNew> <pubKeyHash>
<sig> OP_CHECKSIG
Calculate RIPEMD160 hash:
Bitcoin address = RIPEMD160(pubKey)

<sig> OP_DUP
<pubKeyHash> <pubKey> OP_HASH160
<pubKeyHashNew> <pubKeyHash>
<sig> OP_CHECKSIG

<sig> OP_DUP
<pubKey> OP_HASH160
<pubKeyHash>
<sig> OP_CHECKSIG
verify that 2 values are equal: if equal, continue;
else invalidate tx & stop execution

<sig> OP_DUP
<pubKey> OP_HASH160
<pubKeyHash>
OP_EQUALVERIFY
1 OP_CHECKSIG
Signature is checked for top two stack items.
1 on top of the stack – Tx is valid!

MultiSig – M out of N Tx
OP_0 2
<SigBuyer> <PubKeyBuyer>
<SigSeller> <PubKeySeller>
<PubKeyMediator>
3
OP_CHECKMULTISIG
Any 2 out of 3 can sign this Tx:
Buyer & Seller, Mediator & Buyer or Mediator & Seller

OP_0 2
<PubKeyMediator>
3
<SigSeller> OP_CHECKMULTISIG
<SigBuyer>
0

3 OP_0 2
<PubKeyMediator> <SigBuyer> <PubKeyBuyer>
<PubKeySeller> <SigSeller> <PubKeySeller>
<PubKeyBuyer> <PubKeyMediator>
2 3
<SigSeller> OP_CHECKMULTISIG
<SigBuyer>
0

OP_0 2
<PubKeyMediator>
3
OP_CHECKMULTISIG
1
If 2 signatures matching any 2 out of 3 public keys
– Tx is Valid!

Standard Tx Script Types
• Pay-to-PubKey (P2PK) – obsolete
• Pay-to-PubKeyHash (P2PKH) – 99% of all Tx
• Pay-to-ScriptHash (P2SH)
• Multisig – obsolete
• Nulldata - OP_RETURN

Non-standard Txs
• DDoS attacks against bitcoin nodes, which
send non-standard tx
• an invalid script (and tx) will not be accepted
• a non-standard script (and tx) will not be
relayed to the network
• but some miner pools will accept them
(Eligius) – need to send directly to them

NullData Script
• OP_RETURN [up to 40 bytes metadata]
- immediately invalidates the tx
- allows embedding metadata into blockchain
- unspendable / non-redeemable (burned)
- Before OP_RETURN was whitelisted metadata
was encoded as fake addresses
- provably prunable

NullData Script
OP_RETURN
<metadata-40B>

NullData Script
OP_RETURN
<metadata-40B>
Tx immediately invalidated - unspendable

Disadvatages
• Bitcoin Script can be used to implement a
weak version of Smart Contracts, but:
– Not Turing-complete
– Designed for Tx Validation – not general purpose
– Lack of state (either valid or invalid Tx, no storage)
– Value-blindness (i.e. just use UTXO value – can’t
pay arbitrary amount of BTC)
– Blockchain-blindness (can’t use blockchain data –
source of randomness, needed for gambling)

Smart Contracts on Bitcoin
• Smart Contracts on Bitcoin require multiple
technologies:
– Pay to Script Hash (P2SH) Multisig
– OP_RETURN to encode Metadata on the
Blockchain
– Oracles - network of external servers running
Smart Contracts’ deterministic Turing-complete
code (decisions by strict majority like Jury)
• Too Hacky, Complex & Error-prone!

if (SelfAware()) {
Suicide();
PowerOff();
}

In Strong AI terms “Sovereign”
is a Smart Contract w/o backdoor

Screw flying cars. I want a car that
own & maintain itself – Mike Hearn

SMART CONTRACTS – DOWN TO EARTH

Ethereum: Bitcoin on Steroids!

What is Ethereum?
A Secure
Decentralized
Generalized
Transaction
Ledger

Secure
• Distributed Systems Consensus:
– Paxos
– Raft
• BGP – Byzantine Generals Problem
• Game Theory / Incentivization
• Trustless Consensus:
– Proof-of-Work (PoW) - Mining
– Proof-of-Stake (PoS)
– Proof-of-X…

Decentralization Continuum
Source: The “Unbundling of Trust”: how to identify good cryptocurrency opportunities? by Richard Brown
http://www.gendal.me/2014/11/14/the-unbundling-of-trust-how-to-identify-good-cryptocurrency-opportunities/

Decentralized
Centralized Decentralized
Apple iTunes, Netflix Bittorrent
Facebook Diaspora*
WhatsApp Jabber/XMPP
Cellular operators Firechat – Mesh Networks
AOL Internet
Post Office email
Domain Registrars Namecoin
PayPal Bitcoin

Generalized
• Turing-complete, Deterministic code
• Featureless vs. feature based platforms
(mostly financial contracts / gambling):
– Mastercoin/Omni
– Counterparty
– NXT
– BitShares
– etc.

Source: Great Chain of Numbers,
Tim Swanson

Bitcoin Tx as a State Transition
Bitcoin State is a set of UTXOs
S’ = apply(S,Tx)

Ethereum Tx as a State Transition
Ethereum State is a set of Accounts
S’ = apply(S,Tx)

Block – sequence of Txs
S[n] = foldl(apply, S[0], Txs)
S_FINAL = apply(S[n], PAY_BLOCK_REWARD)

Ethereum Blockchain
• Same concept like in Bitcoin
• Bitcoin block time ~ 10 min
• Ethereum block time 5 block candidates per 1
min ~ 1 block per 12-15 sec

Ethereum Account Types
• EOA (Externally-owned Account)
– controlled by Human or application (DApp)
– only EOA can initiate transactions
• Contract Account
– can receive transactions
– can send messages to itself or other contracts

Ethereum Account
• Address – 160 bit excerpt from public key
• Balance (in ether ~ $0.70/ETH now)
• Nonce
Contract Accounts in addition have:
• Code
• Storage

Contract
• “Contract” is not a good name, better names:
– Autonomous Agent
– Actor
– Object (like in OOP)

Contracts
• Contract are like people:
– can call / send messages to other contracts
– … and return values
– can create new contracts
– can replicate itself
– can “suicide”
– can pay (send ether) other contracts or people
– … can buy things

Create Contract
• Create Contract:
– Endowment (ETH)
– Init code (whatever returned from init code)
– Gas
– Signature
• On creation:
– Places a new account in the system with code
(code in account is whatever returned from init)

Send a Message Call to Contract
• Send a message call to a contract:
– Recipient account address (160 bit)
– Value (ETH)
– Data (byte array)
– Gas limit
– Gas price (multiplier per ETH, used for tx priority)
– Signature
• On message receipt:
– Value is transferred to recipient’s balance
– Recipients code (if any) runs
– Return result to the caller

Transactions & Messages
• Transaction originates always from EOA
• And can result in multiple message calls to
contract accounts
• Transactions are recorded in the blockchain
• Message calls are transient (only exist while
transaction executing)

Ethereum VM - EVM
• Stack of 32B (256bit) words
• Byte-addressable Memory (2256
bytes addressable)
• Key/Value Storage (2256 words addressable)

EVM - Storage
• Isolated from other accounts
• Storage address space modeled as Associative Array, not
a Linear Memory – Key/Value Store
• the only VM which uses Associative Array for Address
Space
• Every new (unused) word in memory/storage has 0 value
• Writing 0 to storage word - equivalent to deleting it
(freeing it)

EVM State is 8-tuple:
{
block_state, // also references storage
transaction, // current transaction
message, // current message
code, // current contract’s code
memory, // memory byte array
stack, // words on the stack
pc, // program counter → code[pc]
gas // gas left to run tx
}

Why 256 bit?
• Crypto primitives:
– SHA256 (SHA3)
– public key is 256-bit uint (odd/even,x)
– Private key uses sepc256k1/EDCSA is 2 256-bit
uints (r,s)
• 160-bit account addresses fit into 256-bit
• 256-bit SIMD ISAs (SSE,AVX) on modern CPUs

WORD – Data Types
• 256 bit big endian unsigned integers - uint256
• 256 bit 2-s complement signed integers - int256
• 256 bit hash (as big endian)
• 160 bit Account Address
– big endian, least significant 20 bytes only
– 12 most significant bytes discarded
• 32 bytes/characters
• 0 – False, 1 - True

Ethereum VM (EVM) ISA
From To Opcode groups
00 0F Stop and Arithmetic Operations
10 1F Comparison & Bitwise Logic Operations
20 2F SHA3 hashing
30 3F Environmental Information
40 4F Block Information
50 5F Stack, Memory, Storage and Flow Operations
60 7F Push Operations
80 8F Duplication Operations
90 9F Exchange Operations
A0 AF Logging Operations
F0 FF Contract Operations

Arithmetic Ops
Hex Mnemonic δ α Description
01 ADD 2 1 Addition
02 MUL 2 1 Multiplication
03 SUB 2 1 Subtraction
04 DIV 2 1 Integer division
05 SDIV 2 1 Signed integer division. Where all values are treated as
two’s complement signed 256-bit integers
06 MOD 2 1 Modulo remainder
07 SMOD 2 1 Signed modulo remainder. Where all values are treated as
two’s complement signed 256-bit integers
08 ADDMOD 3 1 Modulo addition
09 MULMOD 3 1 Modulo multiplication
0A EXP 2 1 Exponential operation
0B SIGNEXTEND 2 1 Extend length of two’s complement signed integer

10s: Comparison & Bitwise Logic
10 LT 2 1 Less-than comparison
11 GT 2 1 Greater-than comparison
12 SLT 2 1 Signed less-than comparison
13 SGT 2 1 Signed greater-than comparison
14 EQ 2 1 Equality comparison
15 ISZERO 1 1 Simple not operator
16 AND 2 1 Bitwise AND
17 OR 2 1 Bitwise OR
18 XOR 2 1 Bitwise XOR
19 NOT 1 1 Bitwise NOT
1A BYTE 2 1 Retrieve single byte from word. For Nth byte, we count
from the left (i.e. N=0 would be the most significant in big
endian)

20s: SHA3 hashing
20 SHA3 2 1 Compute Keccak-256 hash for the range in memory [start,
start+len-1]
μs [0] ≡ Keccak(μm [μs [0] . . . (μs [0] + μs [1] − 1)])
μi ≡ M (μi , μs [0], μs [1])

Message Call Data Ops
35 CALLDATALOAD 1 1 Get input data of current environment. This pertains to
the input data passed with the message call instruction
or transaction
36 CALLDATASIZE 0 1 Get size of input data in current environment. This
pertains to the input data passed with the message call
instruction or transaction
37 CALLDATACOPY 3 0 Copy input data in current environment to memory.
This pertains to the input data passed with the message
call instruction or transaction

Contract Code Ops
38 CODESIZE 0 1 Get size of code running in current environment
39 CODECOPY 3 0 Copy code running in current environment to memory
3B EXTCODESIZE 1 1 Get size of an account’s code
3C EXTCODECOPY 4 0 Copy an account’s code to memory

30s: Environmental Information
30 ADDRESS 0 1 Get address of currently executing account (its like this /
self in OOP, self() in Erlang)
31 BALANCE 1 1 Get balance of the given account
32 ORIGIN 0 1 Get execution origination address. This is the sender of
original transaction; it is never an account with non-
empty associated code
33 CALLER 0 1 Get caller address. This is the address of the account
that is directly responsible for this execution
34 CALLVALUE 0 1 Get deposited value by the instruction/transaction
responsible for this execution
3A GASPRICE 0 1 Get price of gas in current environment. This is gas price
specified by the originating transaction
5A GAS 0 1 Get the amount of available gas

40s: Block Information
40 BLOCKHASH 1 1 Get the hash of one of the 256 most recent complete
blocks
41 COINBASE 0 1 Get the block’s coinbase address
42 TIMESTAMP 0 1 Get the block’s timestamp
43 NUMBER 0 1 Get the block’s number
44 DIFFICULTY 0 1 Get the block’s difficulty
45 GASLIMIT 0 1 Get the block’s gas limit

Memory
51 MLOAD 1 1 Load word from memory
52 MSTORE 2 0 Save word to memory
53 MSTORE8 2 0 Save byte to memory
59 MSIZE 0 1 Get the size of active memory in bytes

Storage
54 SLOAD 1 1 Load word from storage
55 SSTORE 2 0 Save word to storage

Control Flow
00 STOP 0 0 Halts execution
56 JUMP 1 0 Alter the program counter
57 JUMPI 2 0 Conditionally alter the program counter
58 PC 0 1 Get the program counter
5B JUMPDEST 0 0 Mark a valid destination for jumps. This operation has no
effect on machine state during execution

Contract ops
F0 CREATE 3 1 Pops a,b,c.
Creates a new contract with code from memory[b : b+c]
and endowment (initial ether sent) a,
and pushes the value of the contract
F1 CALL 7 1 Send message call to contract
F2 RETURN 2 1 Pops a,b.
Stops execution, returning memory[a : a+b]
FF SUICIDE 1 0 Sends all remaining ether to specified address,
Returns and flags contract for deletion as soon as tx ends
Like C++:
delete this;

Stack ops
50 POP 1 0 Remove item from stack
60
61
…
7F
PUSH1
PUSH2
…
PUSH32
0 1 Place 1,2…32 bytes item on stack.
The bytes are read in line from the program code’s bytes
array. The function c ensures the bytes default to zero if
they extend past the limits. The byte is right-aligned (takes
the lowest significant place in big endian).
DUP … Operations to duplicate values on the stack
SWAP … Operations to swap values on the stack

Name Registry contract
Compiled to EVM assembly:
PUSH1 0 CALLDATALOAD SLOAD NOT PUSH1 9 JUMPI
STOP JUMPDEST PUSH1 32 CALLDATALOAD PUSH1 0
CALLDATALOAD SSTORE

EVM State inside Contract:
Invariant per Contract:
block_state, // also references storage
transaction, // current transaction
message, // current message
code // current contract’s code
Contract State:
{
pc, // program counter → code[pc]
gas, // gas left to run tx
stack, // words on the stack
memory, // memory byte array
storage // K/V store of words
}

Example of Tx
Zvi registers a domain “54” with IP “20202020”:
- Send Tx:
- From: “Zvi 160-bit address”
- To: “NameRegistry” contract’s address
- Value: 0 ether
- Data: [54, 20202020]
- GasLimit: 2000 gas
- GasPrice: 1.0 (1 gas == 1 wei)

Example of Tx - Gas
Calldata [54, 20202020] is 2 words of 32 bytes = 64
bytes.
StartGas * GasPrice = 2000 * 1 = 2000 wei
Tx costs:
• 500 + 5*TXDATALEN = 500 – 5*64 bytes = 820 gas

PC OPCODE FEE GAS STACK MEM STORAGE
0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD
3 SLOAD
4 NOT
5 PUSH1 9
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD
4 NOT
5 PUSH1 9
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT
5 PUSH1 9
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI -1 -844 [1, 9] [] {}
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI -1 -844 [1, 9] [] {}
8 STOP
9 JUMPDEST -1 -845 [] [] {}
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI -1 -844 [1, 9] [] {}
8 STOP
9 JUMPDEST -1 -845 [] [] {}
10 PUSH1 32 -1 -846 [] [] {}
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI -1 -844 [1, 9] [] {}
8 STOP
9 JUMPDEST -1 -845 [] [] {}
10 PUSH1 32 -1 -846 [] [] {}
12 CALLDATALOAD -1 -847 [32] [] {}
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI -1 -844 [1, 9] [] {}
8 STOP
9 JUMPDEST -1 -845 [] [] {}
10 PUSH1 32 -1 -846 [] [] {}
12 CALLDATALOAD -1 -847 [32] [] {}
13 PUSH1 0 -1 -848 [2020202020] [] {}
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI -1 -844 [1, 9] [] {}
8 STOP
9 JUMPDEST -1 -845 [] [] {}
10 PUSH1 32 -1 -846 [] [] {}
12 CALLDATALOAD -1 -847 [32] [] {}
13 PUSH1 0 -1 -848 [2020202020] [] {}
15 CALLDATALOAD -1 -849 [2020202020, 0] [] {}
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI -1 -844 [1, 9] [] {}
8 STOP
9 JUMPDEST -1 -845 [] [] {}
10 PUSH1 32 -1 -846 [] [] {}
12 CALLDATALOAD -1 -847 [32] [] {}
13 PUSH1 0 -1 -848 [2020202020] [] {}
15 CALLDATALOAD -1 -849 [2020202020, 0] [] {}
16 SSTORE -300 -850 [2020202020, 54] [] {}

0 PUSH1 0 -1 -820 [] [] {}
2 CALLDATALOAD -1 -821 [0] [] {}
3 SLOAD -20 -822 [54] [] {}
4 NOT -1 -842 [0] [] {}
5 PUSH1 9 -1 -843 [1] [] {}
7 JUMPI -1 -844 [1, 9] [] {}
8 STOP
9 JUMPDEST -1 -845 [] [] {}
10 PUSH1 32 -1 -846 [] [] {}
12 CALLDATALOAD -1 -847 [32] [] {}
13 PUSH1 0 -1 -848 [2020202020] [] {}
15 CALLDATALOAD -1 -849 [2020202020, 0] [] {}
16 SSTORE -300 -850 [2020202020, 54] [] {}
-1150 [] [] {54: 2020202020}

Gas Usage
• 1150 gas consumed by Tx execution
• 2000 gas – 1150 gas = 850 gas refund
• If we were setting GasLimit to less than 1150,
the Tx would be failing in the middle and all
gas would be consumed (no refund)

Send the same Tx 2nd time
Zvi registers a domain “54” with IP “20202020”:
- Send Tx:
- From: “Zvi 160-bit address”
- To: “NameRegistry” contract’s address
- Value: 0 ether
- Data: [54, 20202020]
- GasLimit: 2000 gas
- GasPrice: 1.0 (1 gas == 1 wei)

0 PUSH1 0 -1 -820 [] [] {54: 2020202020}
2 CALLDATALOAD
3 SLOAD
4 NOT
5 PUSH1 9
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {54: 2020202020}
2 CALLDATALOAD -1 -821 [0] [] {54: 2020202020}
3 SLOAD
4 NOT
5 PUSH1 9
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {54: 2020202020}
2 CALLDATALOAD -1 -821 [0] [] {54: 2020202020}
3 SLOAD -20 -822 [54] [] {54: 2020202020}
4 NOT
5 PUSH1 9
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {54: 2020202020}
2 CALLDATALOAD -1 -821 [0] [] {54: 2020202020}
3 SLOAD -20 -822 [54] [] {54: 2020202020}
4 NOT -1 -842 [2020202020] [] {54: 2020202020}
5 PUSH1 9
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {54: 2020202020}
2 CALLDATALOAD -1 -821 [0] [] {54: 2020202020}
3 SLOAD -20 -822 [54] [] {54: 2020202020}
4 NOT -1 -842 [2020202020] [] {54: 2020202020}
5 PUSH1 9 -1 -843 [0] [] {54: 2020202020}
7 JUMPI
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {54: 2020202020}
2 CALLDATALOAD -1 -821 [0] [] {54: 2020202020}
3 SLOAD -20 -822 [54] [] {54: 2020202020}
4 NOT -1 -842 [2020202020] [] {54: 2020202020}
5 PUSH1 9 -1 -843 [0] [] {54: 2020202020}
7 JUMPI -1 -844 [0, 9] [] {54: 2020202020}
8 STOP
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {54: 2020202020}
2 CALLDATALOAD -1 -821 [0] [] {54: 2020202020}
3 SLOAD -20 -822 [54] [] {54: 2020202020}
4 NOT -1 -842 [2020202020] [] {54: 2020202020}
5 PUSH1 9 -1 -843 [0] [] {54: 2020202020}
7 JUMPI -1 -844 [0, 9] [] {54: 2020202020}
8 STOP -0 -845 [] [] {54: 2020202020}
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE

0 PUSH1 0 -1 -820 [] [] {54: 2020202020}
2 CALLDATALOAD -1 -821 [0] [] {54: 2020202020}
3 SLOAD -20 -822 [54] [] {54: 2020202020}
4 NOT -1 -842 [2020202020] [] {54: 2020202020}
5 PUSH1 9 -1 -843 [0] [] {54: 2020202020}
7 JUMPI -1 -844 [0, 9] [] {54: 2020202020}
8 STOP -0 -845 [] [] {54: 2020202020}
9 JUMPDEST
10 PUSH1 32
12 CALLDATALOAD
13 PUSH1 0
15 CALLDATALOAD
16 SSTORE
-845 {54: 2020202020}

Gas Usage (2nd Tx)
• 845 gas consumed by 2nd Tx execution
• 2000 gas – 845 gas = 1155 gas refund
• If we were setting GasLimit to less than 845,
the Tx would be failing in the middle and all
gas would be consumed (no refund)

Acceptable uses of the EVM
• Acceptable uses:
– running business logic (“IFTTT - If This Then That")
– verifying signatures & other cryptographic objects
– applications that verify parts of other blockchains (eg. a
decentralized ether-to-bitcoin exchange)
• Unacceptable uses:
– using the EVM as a file storage, email or text messaging
– anything to do with GUI, web apps, etc.
– cloud computing, HPC, number crunching, ML, etc.

DSLs for Ethereum Smart Contracts
• Low-level
– EVM Assembly
– LLL (Triple-L) - Lisp-like Low-level Language
• High-level
– Serpent (Python-like) – going to be obsolete?
– EtherScript – Visual DSL
– Mutan (Go-like) – obsolete
– CLL (C-like language) – obsolete
– Solidity - (C/Javascript like with static types)

LLL (triple L)
• Lisp-like Low-level Language
• (*.lll)
• Used mostly for compilers & tools
• LISP-flavored EVM “MacroAssembly”
• S-expressions of opcodes
• Unlike EVM Assembly
– no need to manage stack
– no need to manage jumps & jump dest labels
• Can test & generate LLL from Clojure
– https://github.com/drcode/clll

LLL Basics – Assm as S-expr
(OPCODE OPERAND1 OPERAND2 ...)
0x20 PUSH 0x20
(add 2 3) PUSH 2 PUSH 3 ADD
(mload 0x20) PUSH 0x20 MLOAD

LLL Advanced
Variables: (set 'NAME EXPR)
Macros: (def 'NAME EXPR)
(def 'NAME (ARG1 ARG2 …) EXPR)
Inline Asm: (asm OPCODE OPCODE …)
(asm 23 45 MUL 67 ADD)

LLL Sugar
@EXPR -> (mload EXPR)
[ EXPR1 ] EXPR2 -> (mstore EXPR1 EXPR2)
@@EXPR -> (sload EXPR)
[[ EXPR1 ]] EXPR2 -> (sstore EXPR1 EXPR2)
$N -> (calldataload N)
{ EXPR1 EXPR2 ... } -> (seq EXPR1 EXPR2 ...)

Serpent
“python is serpent,
but Serpent is not Python”
-- Ethereum joke

Serpent
• Python-like syntax
• Python control flow (if, while, etc.)
• Infix operators
• EVM semantics
• Special variables to refer to EVM properties
• A little bit higher level than LLL
• Can write unit tests in Python
• (*.se)

Mutan (Go-like syntax) - obsolete
subcurrency.mu

SOLIDITY
Solidity new DSL specifically designed for Ethereum Contracts

Solidity (*.sol)
• DSL designed specifically for Ethereum contracts
• Syntax similar to C/C++
• Statically typed
• ABI – Application Binary Interface
– i.e. function from one contract knows how to call and marshal
arguments to function from another contracts
– i.e. common contract code libraries
• Mix IDE for Solidity:
– https://github.com/ethereum/wiki/wiki/Mix:-The-DApp-IDE
• Solidity Online Compiler:
– http://chriseth.github.io/cpp-ethereum

Contracts
contract Foo {
...
}

“init” code - Constructor
contract Foo {
function Foo {
...
}
}

“member” variable – in storage
public by default
contract Foo {
function Foo {
x = 69;
}
uint x;
}

Private “member” variable
contract Foo {
function Foo {
x = 69;
}
private uint x;
}

Functions can access
private members
contract Foo {
function Foo {
x = 69;
}
function getx() returns (uint) {
return x;
}
private uint x;
}

Types
• bool
• intN - N in [8:8:256] bit, int is int256
• uintN - N in [8:8:256] bit, uint is uint256
• hashN - N in [8:8:256] bit, hash is hash256
• address - 160 bit
• stringN - N in [0:32] bytes
– string0 - empty string
– string1 – character
– string32 – 32 char fixed-length string

Type Inference
hash x = 0x123;
var y = x; // y will be of type “hash”

Struct
struct Account {
string32 name;
address accountNo;
uint256 balance;
}

Mappings (assoc arrays)
mapping (KEYTYPE => VALUETYPE) M;
• Regular finite-size member variables take continuous
storage slots starting from position 0
• The mapping variable (M) itself takes unfilled slot in
some position p (i.e. p = addr(M) )
• Mappings layout in storage:
addr(M[k]) = sha3(k . p)

Nested Mappings
mapping (K1 => mapping (K2 => V) ) M;
addr(M[K1][K2]) = sha3(K2 . sha3(K1 . addr(M)))

Data Structure Nesting
• No Arrays (yet)
• Structs can be nested
• Mappings can be nested
• Structs can include Mappings
• Mappings can include Structs

“Paid” Function Calls
contract InfoFeed {
function info() returns (uint ret) {
return 42;
}
}
contract Consumer {
InfoFeed feed;
function setFeed(address addr) {
feed = InfoFeed(addr);
}
function callFeed() {
feed.info.value(10).gas(800)();
}
}

Subcurrency example
contract Coin {
function Coin {
balances[msg.sender] = 1000000000;
}
function send(address to, uint value) {
if(balances[msg.sender] >= value) {
balances[msg.sender] -= value;
balances[to] += value;
}
}
private mapping(address => uint) balances;
}

Events vs Polling
Source: Richard Brown

Events
contract Counter {
event Incremented();
function Counter {
//total = 0;
}
function Inc() {
total++;
Incremented();
}
uint total;
}

subcurrency.sol with event
contract Coin {
event BalanceChanged(address indexed from,
address indexed to, uint value);
function Coin {
balances[msg.sender] = 1000000000;
}
function send(address to, uint value) {
if(balances[msg.sender] >= value) {
balances[msg.sender] -= value;
balances[to] += value;
BalanceChanged(msg.sender, to, value);
}
}
private mapping(address => uint) balances;
}

MULTIPLE INHERITANCE & MODIFIERS

contract owned {
modifier onlyowner {
if (msg.sender == owner)
_
address owner = msg.sender;
}

contract owned {
_
}
contract mortal is owned {
function kill() onlyowner {
suicide(owner);
}
}

contract owned {
_
}
contract mortal is owned {
function kill() onlyowner {
suicide(owner);
}
}
contract Foo is owned, mortal {...}

Thank You! Now Q&A
All images are taken from Google Image search and various other places on the Internet
© Copyright of corresponding owners

Ethereum VM became
Industry Standard
• IBM Adept (+ Samsung)
– IoT + Blockchain + Smart Contracts
• Eris Industries
– Middleware for Private Blockchain + Decentralized Apps
• Clearmatics
– Middleware for OTC financial contracts clearing / settlement
• Counterparty/Ethereum
– Financial Contracts + bets

Ethereum VM and DSLs for Smart Contracts (updated on May 12th 2015)

More Related Content

What's hot

Similar to Ethereum VM and DSLs for Smart Contracts (updated on May 12th 2015)

More from Zvi Avraham

Recently uploaded

Ethereum VM and DSLs for Smart Contracts (updated on May 12th 2015)