ethereum.txt

# review: bitcoin

- "blockchain"
- byzantine fault-tolerant consensus in an unpermissioned setting
    - before, only had BFT in permissioned setting
    - bitcoin: applied to digital currency, with limited "smart contract"
      support
- simplest version of this:
    - state machine for currency
    - replicated log (ledger) -> replicated state machine
        - hash chain
        - batching (blocks) as an optimization
        - gossip protocol
    - what can go wrong?
        - double spending attack
    - proof of work -> resolving forks
        - in bitcoin: sha256
        - mining incentives (+ way to bootstrap currency)
            - using POW for fork resolution is bitcoin's key innovation
            - when is tx committed?
- some other interesting pieces
    - adaptive POW / 10 minute block target
    - merkle tree
    - simplified payment verification (SPV)

# ethereum

- ethereum: what if we had bitcoin, but the replicated state machine was a
  turing-complete programmable computer?
- globally shared computation platform; shared blockchain, anyone can deploy
  their own RSM (smart contract); RSMs can talk to each other
- contracts (instantiations of programs) deployed to blockchain, live at
  address, have a particular interface + implementation, can store (public)
  state, store a value (of ether)
    - what other state outside of contracts can be accessed?
        - can talk to other contracts
        - can get blockchain-related info, e.g. prev block hash
        - oracles
- messages are RPCs (function calls with arguments, can carry value too) to
  contracts
- transactions: performed by externally-owned accounts, kick off contract
  execution
- language: EVM (HLLs compile down to EVM)
    - turing-complete, but with "gas"
        - each EVM instruction costs a certain amount of gas (pay for compute +
          storage)
    - pay for gas with ether
        - transactions include max gas, eth/gas
        - if you run out, state change is reverted (but you lose your gas fee)
            - parent executions do not need to revert, only state changes
              resulting from the message execution that ran out of gas
- example applications
    - token currencies
    - decentralized exchange
    - financial derivatives
        - hedging contract (requires oracle)
    - identity and reputation systems
        - similar to blockstack's naming system
    - decentralized file storage
        - merkle tree, SPV-like mechanism to claim ether
        - micropayment channel for retrieving data
            - keep replacing transaction with same nonce
    - decentralized autonomous organizations
- how do you use ethereum
    - what is the architecture in voting dapp tutorial
    - wallet software
        - transactions
        - contracts: contract interface via JSON
    - web3
    - metamask
- some other interesting pieces
    - 17 second block target, rewarding uncle blocks
    - scalability
        - blockchain size: 667 GB
        - bitcoin blockchain size: 216 GB

# questions

- when is a transaction durable?
    - recommended: 100 confirmations (30 minutes), similar to bitcoin's 6
      confirmations in wall clock time
- where do contracts execute?
- how do you choose gas price (eth/gas)?
    - https://ethgasstation.info/
- how do you choose gas?
- what about private state?

# example

- casino smart contract
- bugs:
    - what if contract runs out of money?
    - what if contract is self-destructed?
    - recursive call bug
    - randomness is hard - miner-controlled
        - how would we securely generate random numbers?

# discussion

- ethereum design limitations
- compare ethereum and blockstack
    - what kinds of applications make sense on one platform but not the other
- DAO incident, hard fork / ETH classic, parity wallet incident, and "code is
  law"
- are smart contracts useful? what kinds of applications do they enable? is
  there anything interesting beyond financial tools / speculation?
- how can we have less bugs in smart contracts / how can we make smart
  contracts easier to program?
- what is necessary for the average person to be able to use this technology?
- what do we think about proof of work?