Ethereum

Basics

Permission-less
Distributed storage (like bitcoin)
Computing power (node execute code distributed by participants, which bitcoin has very limited support)
Value token (Ether ETH)
Block time: ~14 seconds (vs Bitcoin 10min)
- maintained by the Ethereum network (protocol) by adjusting the difficulty level for the hash/POW
- block size depends on number of transactions received during the average duration (block time?). miner takes the transactions and add to block.
Block size: Depends, typical 2k (Bitcoin maximum 1M)
Scripting: smart contract
History
- "scripting feature on bitcoin"
- 2015/05 Olympic (test net)
- 2015/07 Frontier (beta)
- 2016/03 Homestead (current)

Usage

Wallet
- connect to the network via the local Ethereum node (is it a node? peer?)
- manages Ether(s) and Smart Contracts
- suitable for simple application
- not suitable for user-friendly or complex application - which requires specific client
DAPP (Decentralized Apps)
- connect via the local node
- interact with contracts on network
- execution is not free (needs Ethers to execute)
Get Ethers
- mining (use wallet to mine for Ethers)
- trade
- Ether faucets (free, google them)
- from friends ...

Smart Contract

computer code
lives on the network
Application Binary Interface (ABI)
enforces agreed rules decided by contracting parties
on certain event performs negotiated actions
contain contract states which changes
expose functions (API) to DAPPs
generate events received by the frontends (DAPPs)
1. Dapp sends transaction
2. Local node propagate the transaction to Ethereum network
3. Transaction get mined
  1. state of contract get changed
  2. event get emitted, data for the event get logged on all nodes in network (all event logs on all nodes)
4. Dapp that is watching event (by subscription) receives events (if watching dapp get notified)
normal contracts & library contracts
- normal contracts can do anything
  - can call another deployed contract
- library contracts
  - it's code is executed in the context of the calling contract
  - if library accesses storage
    - calling contract should have the storage defined correctly : library will be writing to caller's storage
  - http://solidity.readthedocs.io/en/develop/contracts.html#libraries
event usage pattern:
- receive data for transaction (event has return value for invoked method)
- asynchronous trigger (serialized steps)
- cheap data storage (dapp can access the logs and process the events in the logs, for example to report)
  - log data storage: not free but much cheaper (8Gas/byte) than contract storage (20,000 Gas/32 byte)
- contract code cannot access logs data
transactions recorded in the chain
Implementation
- Solidity a most common language
- Serpent
- Lisp like language

Ether (ETH)

Front end always uses wei denomination (among others), 1 wei = 0.000000000000000001 ETH
Where comes those ETH?
- first 60M - presale 2014
- 12M created to fund the development
- 5 Eth = reward for every block
- sometimes 2-3 Eth for non-winning miners (uncle rewards)
Be used to pay "gas"

Gas

Paid by user who is invoking a transaction for execution
- fee = "Gas use in Gas" X "Gas price"
"Gas" is the unit to measure EVM resource usage
- depends on transaction (type / number of op-code executed, fee schedule based) & storage used by the contract
Gas price
- specified by user in transaction
- miner decide acceptable or not
Process
- User specify, in transaction:
  - Start Gas (units), or gas limit : max units of gas originator willing to spend
    - difficult, or even impossible to estimate
    - https://ethstats.net/ - check usual gas limit
  - Gas Price : per unit gas price originator willing to pay
- Escrow: startGas * gasPrice, taken from user
- Transaction executed
- Result
  - Sufficient escrow:
    - Fee = gasUsed * gasPricenumber
    - Refund if applicable
  - Insufficient escrow:
    - Fee paid: startGas * gasPrice (escrow)
    - Out of gas exception!
    - No change made (failed transaction)

EVM - Ethereum virtual machine

Run on Ethereum network node
Execute Ethereum bytecode follows the EVM specifications (part of Ethereum protocol)

Decentralized Apps

Frontend app connects to Ethereum network
Implementation
- Commonly implemented as Single page application (HTML+CSS+JS)
- Can use any other (Java, Python, C++, .NET)
- interface with backend (smart contract on network) via Web3 API
Backend for application implemented as Smart Contract (deployed on Ethereum blockchain)
Data resides in contract instance
All transactions visible to everyone on network
Working
- User invoke contract
  - user needs to pay the "gas" or transaction fee for invoking the contract
  - miner collects the transaction fee
  - transactions validated / mined by miner
  - then recorded in ledger
- Dapp invokes contract functions (API)
Examples
- Ethereum Wallet
- Example - DAPP bidding
  - buyer app
  - seller app
  - contract
    - rules & actions
      - bid()
      - Event: BidReceived
      - withdrawFunds()
    - state data (item, bidding price, etc.)

Ethereum Networks

Live network (real things happen here) ID=1
Test-Net
- Ether has no real value
- Morden (ID=2) retired
- Ropsten (ID=3) current
- KOVAN (not supported by all clients)
- PINKEBY (not supported by all clients)
Private network (ID = assigned)
- data privacy
- as a distributed database without complicated configuration
- consortium
  - industry verticals
  - permissioned
  - to carry out internal transactions & contracts
Clients (wallet, Dapp) can connect to any network (they are of same specification and expected to behave the same way)

Chain Explorers (Block explorer) Applications

Tools for developer to debug what's happening on network
See flow of transactions and creation of block
Public list
Private network
- install an opensource explorer

Consensus Models

Is process by which blocks get created
- a node validate the transactions, create the block using pre-defined process defined by blockchain protocol
- other nodes reach consensus to include / reject the block
Common models for consensus
- Proof-of-Work (bitcoin, Ethereum for now 2017.12)
  - Computationally intensive (expensive)
  - Validate and group transactions
  - Then solve a PUZZLE (that can only be solved by brutal force)
    - Protocol dictate the puzzle (rule, structure, data used to solve the puzzle)
    - Difficulty (amount of computation) of puzzle changes for every block, to make sure blocks are generated at a uniform rate (regulation)
    - Example puzzle (very simplified)
      - Data + X? -> one way hash -> 000...000 (N zeros leading) hash, N decides difficulty
    - Ethereum puzzle
      - Protocol: GHOST
      - Algorithm: ETHash (very memory intensive)
      - Difficulty : network adjusted; block created ~12 seconds
      - Incentive: 5 Ether + fee + uncles
      - Uncles: valid blocks created by non-winning miner not included by network lag
  - Solution included in block as proof of work
  - Multiple miners compete to solve the puzzle and first one solved the puzzle publishes to the network
  - All the nodes validate the block and eventually the block be added
- Proof-of-Stake (Ethereum expected to switch to)
  - Ethereum expected to switch to protocol (CASPER) , reason (comparing to PoW)
    - lower energy consumption
    - lower incentive (lower costs)
    - promote good behavior
    - punishment as part of the protocol as deterrent
  - No competition validators (not referred to as miner in this model) - node selected by network based on protocol dictated strategy
    - chance related to stake of node, and hence chance of reward
    - stake - wealth that user holds on the network
  - Process
    - network selection
    - if validator did not validate, select next validator, until validates
    - complete validation, add block
Incentive driven model (mining)
- validator get rewarded
  - fixed reward in tokens
  - transaction fee

Google Sites

Report abuse