The Ethereum blockchain

Toptal academy Blockchain lectures #5

2018-03-07

ivan.voras@toptal.com

Today's agenda

• Ethereum's new paradigms:
      Account-based balance
      Smart contracts
• Ethereum oracles
• What is gas and how it works
• Transaction structure
• Block structure
• Blockchain structure

Source for all this: Ethereum's
"Yellow paper" (technical spec), at
https://ethereum.github.io/yellowpaper/paper.pdf

Account-based balance

No UTXO in Ethereum :)

Refresher: in Bitcoin, transactions reference outputs of previous transactions as their input. A transaction I create to spend N coins references 1 or more transactions paid to me,
totalling at at least N coins.

In Ethereum, the account / contract state is maintained externally (off-chain, very similar to bitcoin's chainstate), and that includes its balance.

Account-based balance

The result is that Ethereum transactions send money directly from account to account, and the transactions
themselves are irrelevant (do not have to be kept on disk).

Bitcoin:

Private key P signs a transaction referencing previous transactions' outputs X, Y, and Z, all of which are spendable by P. This transaction's output sends N coins to address A, and this output becomes spendable by private key W which "owns" A.

Ethereum:

Private key P signs a transaction transferring N coins to address A. They're spendable by A's private key
W via signature verification.

The "balance" (amount of coins spendable by P and W) is maintained separately.

Ethereum state transitions

Each transaction can change the state of an account, which usually means its balance, but can be other data if the account is actually a contract.

The state of all the accounts and contracts is maintained externally from the blockchain. Miners re-calculate the new state of accounts, and include the Merkle root hash of the new state in the block. This state can thus be re-calculated and verified by all other full nodes.

This "Merkle root hash" is actually the root hash of a Merkle-Patricia trie which is a huge structure covering all accounts ever.

How Ethereum stores state

This actually makes more sense than how Merkle trees are used in Bitcoin. Here, they speed up computation enormously.

Note: each block contains the
NEW ROOT of the Merkle state trie!

(the state is a moving target)

Pros and cons of account states & UTXO

Account states:

• Conceptually simpler
• Space savings by discarding "old" portions of the blockchain
• More fungibility: all coins are the same, no matter by which tx they've arrived

UTXO:

• UTXO offers better privacy if addresses can be freely created (i.e. one address per tx)
• Potentially horizontally scalable (across multiple blockchains -- not yet implemented)

Smart contracts

Here's a bright idea: let's put code into the blockchain!

Some "accounts" have code attached to them,
they become "contracts".

The code can:

• Decide what happens to the coins sent to it
• Create new transactions
• Query blockchain data
• Generate events
• Call other smart contracts
• ... or do anything else since is Turing-complete

Use cases for smart contracts

• Implementation of systems with money-like properties (i.e. tokens / coins)
• Micropayments implementation which at the same time allow the product / media be consumed / unlocked
• Implementation of a health/medical fund where coins are released when a certain number of doctors confirm a diagnosis
• Implementation of a gambling system where coins are released when someone wins
• Implementation of a charty-driven system where a certain portion of the coins is automatically diverted to NGOs
• ...

The problem of "Oracles"

"Oracles" are external systems which input real-world data into the blockchain.

Example: a gambling system for horse races: an oracle exists which sends data about which horse won into the blockchain.

Smart contracts on Ethereum (currently) can ONLY work with data which is in the blockchain. So external information / triggers must first be wrapped in transactions and inputted into the blockchain.

Who do you trust?

Creating oracles

• It's easy enough to roll-your-own, just send data attached to transactions, to smart contract addresses
• Oraclise, http://www.oraclize.it/, a platform which provides an easi(er) way to create oracles
• ChainThis, https://chainthis.com/, similar to Oraclise

In general, Oracles can either periodically, or when requested (by an event generated from a contract) generate data, and send it in a transaction in a call to a smart contract method.

The cost: gas

In addition to Ether, there's a parallel Ethereum currency / concept called "gas".

Gas is a measure of computational work involved in processing a transaction, and this includes the price of execution of a smart contract call (since it's executed on each and every node).

All operations (compiled for the EVM) have a certain price in "gas", and this gas is supplied when the transaction is posted.

Smart contracts can stockpile gas so they can run and/or create new transactions.

What is gas

Each transaction has two numbers attached:

1. "gas limit"
2. "gas price"

The process of determining how much a tx's fee will
be goes like this:

I, the creator of this transaction, are willing to let that the transaction will consume at most "gas limit" gas, which is purchased at a price of "gas price". This fee, calculated as
"gas limit" x "gas price"
will be deducted from my account (in Ether).

Why gas exists

• Having a semi-stable pricing for transactions, removed (or at least lagging in time) from the price of Ether itself. The miners choose which transactions they will include, and they will typically include those with the highest gas consumed.
• Having a computational limit on smart contracts: since every single instruction costs (a small amount of) gas, there is no way infinite loops can be created - because they will be stopped by the gas limit.

Transaction structure

• nonce: transaction sequence number (of the sending account; because there is no UTXO, this is needed to make tx hashes unique, for transactions which are otherwise identical)
• gasprice: price at which gas will be bought
• startgas: gas limit for the tx
• to: destination address
• value: amount of Ether coins (actually in wei units)
• data: attached data, e.g. a smart contract
• v, r, s: ECDSA signature

Transaction structure

Note:

• The public key which proves that the transaction can be created (i.e. the coins spent, etc.), is derived from the ECDSA signature itself, that's why (in contrast to Bitcoin), there is no separate field for the "from" part.
• Smart contract deployment is the mining of a transaction whose data is the smart contract. Its address is created (computed from the sender's address and nonce, with sha3) at that time.
• After the smart contract is deployed, transactions can be sent to it, and its methods called.

Block structure

• parentHash: hash of the previous block's header
• ommersHash: hash of "uncles"
• beneficiary: miner's address
• stateRoot: hash of the state trie's new Merkle root
• transactionRoot: transactions Merkle root
• receiptsRoot: transaction's "receipts" Merkle root
• logsBloom: Bloom filter
• difficulty: mining difficulty
• number: block's height in the chain
• gasLimit: summed values of all gas limits in txs
• gasUsed: summed values of all gas used in txs
• timestamp: timestamp
• extraData: optional additional data
• mixHash: partial mining hash
• nonce: mining guesswork adjustment (64-bit)

Ethereum mining

In principle similar to Bitcoin mining, with some notable changes:

• ETHash: A variant of "Dagger-Hashimoto" PoW mining algorithm, designed to use a large amount of memory (multi-GB, and it's rising), which is presumed to be difficult to implement in ASICs (possible, but fast memory is expensive, so cheaper to use an off-the-shelf GPU) -- sort of like a normal hash function but far more complicated
• 12 second block time target
• The concept of "uncles" or "ommers": alternative minings of the block, i.e. blocks which would be orphans in Bitcoin, included here to "strenghten" the blockchain's immutability; uncles also result in a (limited) reward

Ethereum blockchain plans

• Moving to PoS: doesn't waste electricity as the PoW scheme
• Sharding: moving aways from the "eternal, immutable single ledger" concept, into "sub-blockchains" revolving around a set of addresses and their tx
• Expanded governance: shards could / should enable multiple features to be deployed gradually
• Improvements to privacy ("untracability" of funds), various algorithms, the network protocol, etc.

Inspect some transactions and contracts

Homework

Inspect these addresses in a tool like https://etherscan.io/:

• 0xcafb10ee663f465f9d10588ac44ed20ed608c11e
• 0xb8f1437c742dc042af73d5bd18c8fc985ec8e3b4
• 0xF0160428a8552AC9bB7E050D90eEADE4DDD52843
• 0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe
• 0xBB9bc244D798123fDe783fCc1C72d3Bb8C189413

Note: you can click "Read smart contract", "Read contract source") or a similar button to interact, read-only, with the contract, without sending new tx (if the address is a smart contract). You can also google for them, some of them are famous.

THE END

ivan.voras@toptal.com

Blockchain lecture #5: Ethereum's blockchain

March 2018

Q&A?