Wrocław Blockchain Meetup

#4 Meetup, 22 May 2017

WiFi: wedrowkipubb / wedrowki2016

Venue

Agenda

  • 18:15 - Blockchains, how to they work?
  • 18:45 - Short break
  • 19:00 - Lightning talks
  • 20:00 - Open Mic & Networking

Lightning Talks

  • Ethereum Transactions?
    Tomasz Drwięga
     
  • Parity-Bitcoin
    Marek Kotewicz

Join our slack

Contact the organizers

Blockchains,

how do they work?

Marek Kotewicz

Introduction for developers

  • What is blockchain / blockchain technology?
  • Decentralization?
  • Consensus?
  • Incentives?
  • What is Bitcoin?
  • What is Ethereum?
  • Glossary

Client:
Let's build a bank from scratch!

You (developer):
What are the requirements?

Possible Actions:

  • Transfer
    (who, fromAccount, toAccount, value)
  • BalanceOf
    (account)

Example Interaction:

User X transfers $5 from account A1 to account A5

 

Database

API

 

User X

User Y

User Z

Questions?

  • Is any user allowed to send funds from every account?
  • Can you send more than you have?
  • Can you send funds twice?
  • How do we verify users?
  • What is the initial state of the database (Genesis)?

Answers:

  • No, each user controls a single account.
  • No, you can't send more than you have.
  • No, when you send funds you don't control them any more.
  • User need to prove they exist (KYC) and then we'll give them some credentials.
  • We control the database anyway, so we can just alter the records :)


Database

API

 

User X

User Y

User Z

 

Admin

Authenticate

Enforce Rules

Persist State

Trusted Zone

Bank

  • Authenticates the user
  • Authorizes the user
  • Checks the rules
  • Does the transfer (atomicly)
  • Persists new state

User

  • Sends a transfer requests
  • Adds credentials
  • Trusts Bank to perform requested action

If users want to query account balance often Bank's API becomes a bottleneck.

Can we do better, can we avoid the bank?

A State Machine

State + Transitions

A State Machine

State + Transition

BalanceOf(A) = 10
BalanceOf(B) = 0

BalanceOf(A) = 5
BalanceOf(B) = 5

Transfer(A, B, 5)

Let's limit ourselves

a little bit

Account balances are updated once a day.

BalanceOf(A) = 10
BalanceOf(B) = 0
BalanceOf(C) = 0


BalanceOf(A) = 0
BalanceOf(B) = 5
BalanceOf(C) = 5


Day 1

Day 2

Transition
(list of transactions)

  1. transfer(A, B, 5)
  2. transfer(A, C, 5)

+
Transactions

+
Transactions

+
Transactions

 

Database

API

 

User X

User Y

User Z

Each user can now query the database locally

(at least during a day)

What if the Bank could let users do transitions locally?

User X

User Y

User Z

If users can do everything locally the Bank is not needed!

Problems to solve

  • How to authenticate users?
  • How to enforce the rules?

Why?

  • We need to trust the Bank
  • The Bank is intermediary:
    • weakest link / bottleneck
    • operational cost == fees!

Public-key cryptography

Authentication

Alice's Public Key

Alice's Private Key

Bob's Public Key

Bob's Private Key

Sign with Private

verify with Public

Alice's Private Key

Message

Signature

Sign with Private

verify with Public

Alice's Public Key

Message

Signature

Alice sent it!

Given a list of transactions and a previous state

we can compute the current one

​transfer(A, B, 5)
Alice's Signature
​transfer(B, C, 5)
Bob's Signature

That's a blockchain!

​transfer(A, B, 5)
Alice's Signature
​transfer(B, C, 5)
Bob's Signature
​transfer(B, A, 5)
Bob's Signature

Transactions packed together in blocks,

linked to each other to encode time-relations.

Single Block

Block Number 5
Date 18:00 13.02.2017
Expected State (Block Hash)
Previous Block State (Chain Link)
List of transactions

We don't store the whole State in a block.

Instead we just store a list of transactions, perform transition and check if the State is the same as expected.

Ok, so the nodes can just broadcast the state transitions, right?

No, because of double spend.

User A

User C

User B

Users cannot trust one another.

or propagation time may vary

​transfer(A, B, 5)
Alice's Signature
​transfer(A, C, 5)
Alice's Signature

Ok, so we can just collect all transactions and submit a block once a day

Yes, but everyone can submit their own block, how do you know which one is "the correct one"?

If anyone can submit a next valid block how do we choose the one?

Maybe let's try to limit who can submit a new block?

Consensus Mechanisms

  • Proof of Authority (centralized):
    • Only "the Bank" can submit new blocks
    • Alice submits even blocks, Bob submits odd ones
  • Proof of Work (decentralized):
    • The first one to solve a difficult puzzle can submit a new block

Single Block

Block Number 5
Date 18:00 13.02.2017
Expected State (Block Hash)
Previous Block State (Chain Link)
List of transactions
Puzzle / Consensus Proof Block Number + 5 = ?

We need a puzzle that is:

1. Trivial to validate

2. Difficult to compute

One-way functions

e.g. Crypto... Hash Functions

      DATA
)
f(
= hash
BlockHash
)
sha256(
= 0x000...
Nonce

Puzzle: Find a Nonce that hashed together with current block hash gives a hash starting with X zeros

Canonical Chain

​transfer(A, B, 5)
Alice's Signature
​transfer(B, C, 5)
Bob's Signature
​transfer(B, A, 5)
Bob's Signature
​transfer(B, C, 5)
Bob's Signature

Longest in some metric

Consensus ensures the blocks are produced in expected rate via

Difficulty Adjustment / Protocol Delays

Ok, so why would I ever waste my computing power to submit new blocks?

It's incentivized - You will earn money
(and it's called mining)

Summary

  • State + Transition = New State
  • Block = (State, Transactions)
  • Decentralized Consensus:
    • Who can submit a new block?
  • Nodes are broadcasting signed transactions
  • Miners are producing and broadcasting new blocks 
  • Nodes are processing new blocks and performing state transition

What is Bitcoin?

Bitcoin is the first public blockchain ever.

Block Time 10 minutes
Consensus Proof of Work - hashcash
State Account Balances of BTC / UTXO*
Transactions Value Transfers*
Launched 2009

What is Ethereum?

Ethereum is the World Computer

Block Time 14 seconds
Consensus Proof of Work - ethash*
State Arbitrary
Transactions Turing-complete / programmable
Launched 2015

I'm most probably out of time 

So let's jump to glossary

List of important words

  • Genesis Block
  • Blockchain
  • Protocol
  • Consensus
  • Incentives
  • Miner
  • Hashing Power
  • Hard/Soft Fork
  • Canonical Chain
  • Chain re-org

Any questions?

  • Decentralization
  • Distributed Ledger
  • Bitcoin
  • UTXO
  • Ethereum / EVM
  • Smart Contracts
  • Altcoins
  • Tokens
  • Fiat currency

Ethereum Transactions

Tomasz Drwięga

Parity-Bitcoin

Marek Kotewicz

Thanks!

See you next time!

Join our slack, mailto:tomasz.drwiega@gmail.com

Blockchain Meetup #4

By Tomasz Drwięga

Blockchain Meetup #4

  • 749