Dissecting Ethereum

Internals of a public blockchain

24 July 2017

EIT Digital, Budapest

As seen by the world

Decentralized computer network

• Owned and operated by random people ⇔ no central authority or control
• Assembled from various open source clients ⇔ security by public scrutiny

Public for anyone to join

Download and run your own node

• Geth (CLI), Mist (UI), Parity (WebUI)
• Connect to main or test networks

Phases of connecting to Ethereum

• Discover peers via public bootnodes
• Randomly connect peers to stabilize
• Exchange data to uphold the system

As seen by the machine

Database of financial accounts

• Tracks all past versions of the data ⇔ publicly auditable historical records
• Rooted at an immutable initial state ⇔ multiple global databases co-exist
• Modifications adhere to strict rulesets ⇔ balances calculated, not shared

Updated from malicious computers

• Remote content is untrusted ⇔ operate on signed change requests
• Requests are distributed in groups ⇔ generate own data version locally
• Competing groups and versions happen ⇔ computers converge eventually

As seen by the user

Giberish account numbers

E.g. 0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359 😱

• Accounts are cryptographic keys ⇔ no username, no operator, no recovery
• Each key owns an associated address ⇔ without the key, funds are lost forever

Accounts useful only to create transactions

• Provide the details (recipient, amount, etc)
• Digitally sign it (computer or hardware wallet)
• Wait for the network to process the transaction

Special snowflakes ❄

E.g. 0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359... again?! 😕

• Accounts can be programs ⇔ react to events in the network
• Programs do not have keys ⇔ operate unstoppably as coded
• Does everything a user can ⇔ own, transact, create programs

Who the heck thought this is a good idea?!

As seen by the developer

Programmable global infrastructure

Nodes run a custom virtual machine

• Stack-based bytecode interpreter ⇔ multiple higher level languages
• Transactions are VM executions ⇒ transfer, then run available code
• Transactions carry data payload ⇒ user input and code deployment

Resource consumption and the halting problem

• Programs run in varying time ⇔ fees based on VM instructions
• Complexity up to infinite loops ⇔ capped maximum resource use

.code
  PUSH 60
  PUSH 40
  MSTORE
  PUSH FFFFFFFF
  PUSH 10..0
  PUSH 0
  CALLDATALOAD
  DIV
  AND
  PUSH A5F3C23B
  DUP2
  EQ
  PUSH [tag] 2
  JUMPI
tag 1
  JUMPDEST
  PUSH 0
  DUP1
  REVERT
tag 2
  JUMPDEST
  CALLVALUE
  ISZERO
  PUSH [tag] 3
  JUMPI
  PUSH 0
  DUP1
  REVERT
tag 3
  JUMPDEST
  PUSH [tag] 4
  PUSH 4
  CALLDATALOAD
  PUSH 24
  CALLDATALOAD
  PUSH [tag] 5
  JUMP
tag 4
  JUMPDEST
  PUSH 40
  MLOAD
  SWAP1
  DUP2
  MSTORE
  PUSH 20
  ADD
  PUSH 40
  MLOAD
  DUP1
  SWAP2
  SUB
  SWAP1
  RETURN
tag 5
  JUMPDEST
  DUP2
  DUP2
  ADD
tag 6
  JUMPDEST
  SWAP3
  SWAP2
  POP
  POP
  JUMP [out]
.data

Supporting user-friendly packaging

Only through programs running locally

• Directly via the user's node ⇔ exposes a large attack surface
• Indirectly through wrappers ⇔ limited app specific features
• Custom embedded own node ⇔ ultimate user experience

As seen by the initiated

Network stats – Rinkeby Testnet –

https://stats.rinkeby.io/