Scribd
Upload
209 views31 pages

Ethereum in 40 Minutes

Ethereum is a blockchain protocol that allows developers to build decentralized applications and execute smart contracts. It features a built-in programming language that allows anyone to define new applications with individual rules by creating contracts. Ethereum uses a system of "gas" to charge fees for computational steps and avoid infinite loops. Developers can build applications that send ETH, read/write storage, and call other contracts.

Uploaded by

ErmirLeka
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
209 views31 pages

Ethereum in 40 Minutes

Ethereum is a blockchain protocol that allows developers to build decentralized applications and execute smart contracts. It features a built-in programming language that allows anyone to define new applications with individual rules by creating contracts. Ethereum uses a system of "gas" to charge fees for computational steps and avoid infinite loops. Developers can build applications that send ETH, read/write storage, and call other contracts.

Uploaded by

ErmirLeka
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

Ethereum in 25 Minutes

A guided tour through the depths of the Merkle


underworld
Why ethereum?
● Seeming public consensus circa 2013: blockchains are
useful for… stuff
● Not just money! Asset issuance, crowdfunding, domain
registration, title registration, gambling, prediction
markets, internet of things, voting, hundreds of
applications!
Problem: most existing blockchain protocols were
designed like this:
Or, at best, like this:
So… why not make a protocol that works like this?*

*Special thanks to Microsoft for sponsoring this conference


The concept

It’s a blockchain… yawn


With… a few tiny additions
● A built-in programming language
● Two types of accounts
○ User accounts (controlled by private keys)
○ Contracts (controlled by code)
● Anyone can create an application with any rules by
defining it as a contract
DNS: The Hello World of Ethereum

data domains[](owner, ip)

def register(addr):
if not self.domains[addr].owner:
self.domains[addr].owner = msg.sender

def set_ip(addr, ip):


if self.domains[addr].owner == msg.sender:
self.domains[addr].ip = ip
State vs History
● State = “current” information
○ Account balances
○ Nonces
○ Contract code and contract storage
● History = things that happened
○ Transactions
○ Receipts
● Currently, all “full” nodes store state, some store
history and some do not store history
State
● State consists of key value mapping addresses to
account objects
● Every account object contains 4 pieces of data:
○ Nonce
○ Balance
○ Code hash (code = empty string for private
key-controlled accounts)
○ Storage trie root
Code execution
● Every transaction specifies a TO address it sends to
(unless it’s creating a contract)
● The TO address’s code runs
● Code can:
○ Send ETH to other contracts
○ Read/write storage
○ Call (ie. start execution in) other contracts
Code execution
● Every (full) node on the blockchain processes every
transaction and stores the entire state, just like
Bitcoin
○ It’s bold because it’s important.
Gas
● Halting problem
○ Cannot tell whether or not a program will run
infinitely
● Solution: charge fee per computational step (“gas”)
● Special gas fees also applied to operations that take up
storage
Gas limit
● Counterpart to the block size limit in bitcoin
● Voting mechanism (can upvote/downvote gas limit by
0.0976% every block)
● Default strategy
○ 4712388 minimum
○ Target 150% of long-term EMA of gas usage
Transactions
● nonce (anti-replay-attack)
● gasprice (amount of ether per unit gas)
● startgas (maximum gas consumable)
● to (destination address)
● value (amount of ETH to send)
● data (readable by contract code)
● v, r, s (ECDSA signature values)
Receipts
● Intermediate state root
● Cumulative gas used
● Logs
Logs
● Append-only, not readable by contracts
● ~10x cheaper than storage
● up to 4 “topics” (32 bytes), plus data
● Intended to allow efficient light client access to event
records (eg. domain name changed, transaction
occurred, etc)
● Bloom filter protocol to allow easier searching by topic
Ethereum Virtual Machine
● Stack
● Memory
● Storage
● Environment variables
● Logs
● Sub-calling
High-level languages
● Compile to EVM code
● Serpent
● Solidity
● LLL
The ABI
● Function calls are compiled into transaction data
e638984d666f6f2e65746800000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000
0000000000000012345678

● First 4 bytes: function ID


● Next 32 bytes: first argument (“foo.eth”)
● Next 32 bytes: second argument (18 52 84 120 -> 0x12345678)
A cool new mining algorithm
● Goal: GPU-friendly, ASIC-hard
● CPU-friendly too risky a target, GPU “safe” balance,
also limits botnet/AWS concerns
● Uses memory-hardness to achieve this goal
● Uses a multi-level DAG construction to achieve this
with light-client friendliness
A cool new mining algorithm
● Full node mining strategy: re-build the full DAG every
30000 blocks, quickly compute mixhashes
● Light node verification strategy: re-build only the
cache every 30000 blocks, more slowly compute
mixhash once by computing 256 DAG nodes on the fly
○ Less efficient, but we only need to do this once
Fast block times
● The problem with fast block times: stale rates due to
network latency
Normally, this leads to centralization risks

● Last block zero stale rate effect


● Network connectivity economies of scale
Our solution: uncles
● Our solution: allow stale blocks to be re-included and
receive most of the reward
● Cuts centralization incentives by ~85%
Merkle trees
Merkle trees

Allow for efficiently verifiable proofs that a transaction


was included in a block
Merkle trees in Ethereum
Merkle trees in Ethereum
● Every block header contains three tries
○ Transactions
○ State
○ Receipts
● Patricia trees used in order to allow efficient
insert/delete operations
Future directions
● PoS
● Privacy support (ZK-snark precompiles, ring sigs, etc)
● Blockchain rent
● VM upgrades
● More flexible use of storage
● Scalability

You might also like