Bitcoin works by having miners validate transactions that are technically short scripts written in a very simple scripting language. If the script runs and doesn't return an error, it's a valid transaction and gets included in the blockchain. That's how you're able to have m-of-n transactions, timelocked transactions, microtransaction channels, etc.

Ethereum's core difference is that its scripting language is Turing complete, with each operation in the scripting language having a specific cost that informs the fee required for each transaction. So now you can write Smart Contracts which are much more powerful contracts than you ever could with Bitcoin.


The Ethereum releases are:

  • Prerelease Step 0: Olympic testnet - launched May 2015
  • Release Step One: Frontier - launched 30 July 2015
  • Release Step Two: Homestead - launches 14 March 2016 (Pi Day)
  • Release Step Three: Metropolis - TBA
  • Release Step Four: Serenity - TBA

Homestead was introduced automatically at block 1,150,000.


Ethereum also has it’s own cryptocurrency token called Ether, denominated ETH. Ether is also used to pay for transaction fees and computational services on the Ethereum network.

Every 12 seconds, on average, a new block is added to the blockchain with the latest transactions processed by the network and the computer that generated this block will be awarded 5 ether.

All ether balances and values are denominated in units of wei: 1 ether is 1e18 wei.


Gas is the internal pricing for running a transaction or contract in Ethereum. Gas can only be paid for in Ether. You can view the current gas price at Etherscan.

Ethereum Virtual Machine

The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts. It is sandboxed and also completely isolated from the network, filesystem or other processes of the host computer system. Every Ethereum node in the network runs an EVM implementation and executes the same instructions. Ethereum Virtual Machines have been implemented in C++, Go, Haskell, Java, and other languages.

Smart Contracts

Smart contracts are compiled down to EVM bytecode and deployed to the Ethereum blockchain for execution. They can be written in Solidity (a language library with similarities to C and JavaScript), Serpent (similar to Python), LLL (a low-level Lisp-like language), and Mutan (Go-based, but deprecated).

Currently, the Ethereum protocol could process only 25 transactions per second. This is because every node is calculating all the smart contracts in real time.


Like in Bitcoin, users must pay small transaction fees to the network. The sender of a transaction must pay (with Ether) for each step of the “program” they activated, including computation and memory storage.

These transaction fees are collected by the miners, which are nodes in the Ethereum network that receive, propagate, verify, and execute transactions. The miners then group the transactions – which include many updates to the “state” of accounts in the Ethereum blockchain – into what are called “blocks”. Just as in the Bitcoin network, miners are tasked with solving a complex mathematical problem in order to successfully “mine” a block (“Proof of Work”). Ethereum chose a memory-hard computational problem (Ethash), to discourage the use of ASICs.


Whereas the Bitcoin blockchain was purely a list of transactions, Ethereum’s basic unit is the account. The Ethereum blockchain tracks the state of every account, and all state transitions on the Ethereum blockchain are transfers of value and information between accounts. There are two types of accounts:

  • Externally Owned Accounts (EOAs). An EOA:
  • has an ether balance;
  • can send transactions (ether transfer or trigger contract code);
  • is controlled by private keys;
  • has no associated code.
  • Contract Accounts, which are controlled by their contract code and can only be “activated” by an EOA. A Contract Account:
  • has an ether balance,
  • has associated code,
  • code execution is triggered by transactions or messages (calls) received from other contracts.
  • when executed: can perform operations of arbitrary complexity (Turing completeness) and can manipulate its own persistent storage, i.e., can have its own permanent state, and can call other contracts.

Contracts generally serve four purposes:

  • Maintain a data store representing something which is useful to other contracts or to the outside world.
  • Serve as a sort of externally-owned account with a more complicated access policy; this is called a “forwarding contract” and typically involves simply resending incoming messages to some desired destination only if certain conditions are met.
  • Manage an ongoing contract or relationship between multiple users.
  • Provide functions to other contracts, essentially serving as a software library.

For most users, the basic difference between EOAs and Contract Accounts is that human users control EOAs - because they can control the private keys which give control over an EOA. Contract accounts, on the other hand, are governed by their internal code.

All action on the Ethereum block chain is set in motion by transactions fired from externally owned accounts. By default, the Ethereum execution environment is lifeless; nothing happens and the state of every account remains the same. However, any user can trigger an action by sending a transaction from an externally owned account, setting Ethereum’s wheels in motion. If the destination of the transaction is another EOA, then the transaction may transfer some ether but otherwise does nothing. However, if the destination is a contract, then the contract in turn activates, and automatically runs its code.

Each account has a persistent memory area which is called storage. Storage is a key-value store that maps 256-bit words to 256-bit words. A contract can neither read nor write to any storage apart from its own.

The second memory area is called memory, of which a contract obtains a freshly cleared instance for each message call. Memory is linear and can be addressed at byte level, but reads are limited to a width of 256 bits, while writes can be either 8 bits or 256 bits wide.


  1. There is no visual way to check if an address is a contract or an EOA. One of the goals of Ethereum is for humans and smart contracts to both be treated equally. You can however use a blockchain scanner to check if there is any code at the address.

  2. Unlike Bitcoin, there is no need for Hierarchical Deterministic (HD) wallets in Ethereum. Bitcoin operates under a UTXO (unspent transaction output) system, which necessitates new addresses for each transaction. Ethereum, in contrast, operates on an account based system. While it would be possible to deterministically generate a tree of accounts from a single seed in Ethereum, there's really no need to, because a single account can handle all of your transactions. The only reason to use a HD wallet would be for extra privacy.

Smart Contracts

The term smart contracts refers to code in a Contract Account.

It isn't possible to decompile a smart contract back to Solidity source code, but you can decompile the bytecode into opcodes - for example use

Private keys, Public keys, and Addresses

For an EOA, there are three main steps to get from private key to address:

  1. Create a random private key (64 (hex) characters / 256 bits / 32 bytes)
  2. Derive the public key from this private key (128 (hex) characters / 512 bits / 64 bytes)
  3. Derive the address from this public key. (40 (hex) characters / 160 bits / 20 bytes)

Private keys are 64 hexadecimal characters. Every single string of 64 hex are, hypothetically, an Ethereum private key that will access an account.

An Ethereum address represents an account. For an EOA, the address is derived as the last 20 bytes of the public key controlling the account, e.g., `cd2a3d9f938e13cd947ec05abc7fe734df8dd826. This is a hexadecimal format (base 16 notation), which is often indicated explicitly by appending 0x to the address. Ethereum addresses are hence 40 hexadecimal characters and start with a 0x.

Even though a lot of people call the address the public key, it's actually not the case in Ethereum. There is a separate public key that acts as a middleman that you won't ever see.

To create an address go to

Note: Never enter an Ethereum address manually! Ethereum addresses don't have checksums.

Whereas the address of an EOA is determined from the public key, the address of a contract account is determined at the time the contract account is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).


Accounts are the most basic way to store Ether. They are simple public/private keypairs, which you use to sign transactions. You don't need to do anything to "register" an account with the network, just generate one and send some ether to it.

Wallets are smart-contracts that allow for advanced features such as transaction logging, multisig, withdrawal limits, and more. In order to create a wallet, you need to deploy the contract to the blockchain, which requires Ether. You need to make sure you keep track not only of the keys required to access the wallet, but also the wallet address. Unlike with accounts, wallet addresses are not very easily derivable from the private key (although it's not the end of the world if you lose the wallet address, you can use a block explorer to find what contracts you've created recently). Technically you can recover the address from just the account that created it and the nonce of the transaction, but that's a hassle.

Creating Accounts does not cost any gas; but creating Wallets does. In fact, Wallets incur a cost whenever you use them.


The term transaction is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account to another account on the blockchain.

Transactions contain:

  • the recipient of the message,
  • signature identifying the sender and proving their intention to send the message via the blockchain to the recipient,
  • VALUE field - The amount of wei to transfer from the sender to the recipient, an optional data field, which can contain the message sent to a contract,
  • a STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take,
  • a GASPRICE value, representing the fee the sender is willing to pay for gas. One unit of gas corresponds to the execution of one atomic instruction, i.e., a computational step.

Contracts have the ability to send messages to other contracts. Messages can be conceived of as function calls.

A message contains:

  • the sender of the message (implicit).
  • the recipient of the message
  • VALUE field - The amount of wei to transfer alongside the message to the contract address,
  • an optional data field, that is the actual input data to the contract
  • a STARTGAS value, which limits the maximum amount of gas the code execution triggered by the message can incur.

Essentially, a message is like a transaction, except it is produced by a contract and not an external actor.


A node is a piece of software that connects to other nodes, thus participating in the formation of the Ethereum network. A node stores the blockchain, and a node may mine (but doesn't have to). All interaction with the blockchain (interaction with contracts, etc) needs to go via a node.

If you don't wish to run your own node, you can use a public one such as

View a map of Ethereum nodes at


An Ethereum client refers to any node able to parse and verify the blockchain, its smart contracts and everything related. It also allows you/provides interfaces to create transactions and mine blocks which is the key for any blockchain interaction.

  • Official reference implementations (CLI)

eth - C++ client of the webthree project. It was formerly known as cpp-ethereum:

geth - Golang client of the go-ethereum project:

pyethapp - Python client of the pyethereum project:

  • Official reference implementations (GUI)

mist which works on top of geth or eth and aims to be a DApp browser and currently implements the ethereum-wallet-dapp.

alethzero is internally called the hardcore client but it's being deprecated. Third party implementations (CLI)

  • Non-official clients implementing the yellow paper specification are:

parity - Rust client by ethcore:

ethereumj - Java client by the team:

ethereumjs-vm - Ethereum Virtual Machine in Javascript:

ethereumH - Haskell client from consensys, but it's not developed anymore:

ruby-ethereum - Ruby client:

node-blockchain-server - simple Javascript server:

  • Third party implementations (GUI)

etherwall, a Qt client:


Ethereum enables the decentralised web, referred to as ‘web 3’. The web3 stack is:

A Dapp (‘decentralized app’) consists of two parts: a frontend, written in HTML, and a backend (think of it as the ‘database’ for the frontend).

Good news for developers: if you like bootstrap, or any other framework, you can continue using them, as the frontend of dapps have full network access. In fact, for all intent and purposes, developing a frontend for a Dapp written HTML is the exact same as developing a website.

Because Ethereum relies on cryptographic principles to function, every Dapp knows the pseudonymous identity of each user. Hence users won’t need to ‘create accounts’ or ‘log on’ to access your dapps.

The frontend code ‘listens’ to changes on the blockchain and visually update the client as it is notified of updates. It can also makes calls to the underlying backend code in the form of calls to smart contracts functions, usually with the help of web3.js.

An ideal dapp should be unstoppable. The backend question is taken care off by using smart contracts on the Ethereum blockchain. For the frontend, an ideal dapp would not be hosted anywhere centralized, but instead held a self-contained, compressed package within a decentralized storage platform such as SWARM.

That package would decompress into a series of folders and files, which would be recognized by an Ethereum browser as a valid dapp structure. At the moment, that structure consists of HTML + JS files, often in the form of a Meteor static assets.

This package would be digitally signed and referenced from within the blockchain itself in order for the author to invalidate it and ‘force’ a software update whenever needed.

dApp browsers

Dapp browsers include the following:

  • Mist - official GUI dapp browser developed by the foundation.
  • Status - Mobile Ethereum browser.
  • MetaMask - An in-browser GUI.
Ethereum Name Service (ENS)

The primary goal of ENS is to resolve human-readable names, like ‘myname.eth’, into machine-readable identifiers, including Ethereum addresses and other identifiers.

Top-level domains, like ‘.eth’ and ‘.test’ are owned by smart contracts called registrars, which specify rules governing the allocation of their subdomains.

ENS is deployed on mainnet at 0x314159265dd8dbb310642f98f50c066173c1259b, where users may register names under the eth TLD, which uses an auction based registrar.

To register a name go to

ERC20 tokens

Ethereum tokens are not built into its blockchain. To remedy this problem, the EIP20 protocol has been accepted by Ethereum community and became the first standard protocol for token creation and development (ERC20).

The following is an interface contract declaring the required functions and events required to meet the ERC20 standard:

contract ERC20 { function totalSupply() constant returns (uint totalSupply); function balanceOf(address _owner) constant returns (uint balance); function transfer(address _to, uint _value) returns (bool success); function transferFrom(address _from, address _to, uint _value) returns (bool success); function approve(address _spender, uint _value) returns (bool success); function allowance(address _owner, address _spender) constant returns (uint remaining); event Transfer(address indexed _from, address indexed _to, uint _value); event Approval(address indexed _owner, address indexed _spender, uint _value); }

The meanings of these functions are:

  • totalSupply() - Total number of tokens in circulation
  • balanceOf(A) - Number of tokens belonging to A
  • transfer(A,x) - Send x tokens to A
  • transferFrom(A,x) - Withdraw x tokens from A
  • approve(A,x) - Approve A to withdraw tokens from me
  • allowance(A,B) - How much B can withdraw from A

Most of the major tokens on the Ethereum blockchain are ERC20-compliant. View popular tokens or use the Etherscan token search or

A minimal open-source ERC20 dashboard/wallet (that uses etherscan as node provider) can be found at

You may issue and interact with tokens using

Note: the ERC223 standard is a newer standard that can also be considered.


The best way to start with Solidity is to use the Remix browser-based IDE, or Ethereum Studio.

The Solidity docs are located at

Here are some basic concepts:

  • The version pragma pragma solidity ^0.4.0; indicates the source file will not compile with a compiler earlier than version 0.4.0.
  • import "filename"; imports all global symbols from “filename”.
  • uint storedData; defines a state variable of type uint which will be permanently stored in contract storage.
  • modifier onlySeller() {...} Modifiers can be used to easily change the behaviour of functions, for example to automatically check a condition prior to executing the function.
  • function abort() onlySeller {...} Functions are the executable units of code within a contract.
  • struct Voter { uint weight; bool voted; } Structs are custom defined types that can group several variables.
  • enum State { Created, Locked, Inactive } Enums can be used to create custom types with a finite set of values.
  • bool, int/uint, address (Holds a 20 byte value, which is the size of an Ethereum address).
  • bytes1, bytes2.. are fixed-size byte arrays.
  • mapping(address => uint) public balances; Mappings can be seen as hashtables which are virtually initialized such that every possible key exists
Do it yourself training!

Here are some exercises to experience Ethereum for yourself:

  • Basic operations
  • Create ERC20 token

to be continued...