solutions.hamburg 2016 blockchain basics

1. BLOCKCHAINS TO THE RESCUE
DECENTRALISED WHATEVER

2. DECENTRALISED WHATEVER - BLOCKCHAINS TO THE RESCUE
ABOUT ME
▸ Maximilian Reichel
▸ Silpion IT-Solutions GmbH
▸ Web-Engineering

3. DECENTRALISED WHATEVER - BLOCKCHAINS TO THE RESCUE
TOC
▸ blockchain basics
▸ block generation (proof-of-work, proof-of-stake)
▸ consensus and security considerations
▸ decentralised applications (Ðapps)
▸ some use cases

4. BLOCKCHAIN BASICS
IT’S JUST A DATABASE
▸ distributed
▸ immutable
▸ permanent
▸ verifiable
▸ auditable

5. BLOCKCHAIN BASICS
CENTRALISED
Source: On Distributed Communications Networks, Paul Baran, 1962

6. BLOCKCHAIN BASICS
DECENTRALISED
Source: On Distributed Communications Networks, Paul Baran, 1962

7. BLOCKCHAIN BASICS
DISTRIBUTED
Source: On Distributed Communications Networks, Paul Baran, 1962

8. BLOCKCHAIN BASICS
PLAIN OLD DATABASE
TxId TxType Sender Recipient Payload
#1000 Asset-Transfer Account A Account B 10
#1001 Asset-Transfer Account B Account C 5
#1002 Asset-Transfer Account A Account C 5
#1003 Asset-Transfer Account C Account A 10

9. BLOCKCHAIN BASICS
BLOCK
TxId TxType Sender Recipient Payload
<HASH> Asset-Transfer Account A Account B 10
<HASH> Asset-Transfer Account B Account C 5
<HASH> Asset-Transfer Account A Account C 5
<HASH> Asset-Transfer Account C Account A 10
Merkle Root
Previous Block
<HASH>
<HASH OF PREVIOUS BLOCK HEADER>
TransactionsHeader

10. BLOCKCHAIN BASICS
BLOCKCHAIN
TxId TxType Sender Recipient Payload
… … … … …
… … … … …
… … … … …
… … … … …
Previous Block
Merkle Root
<HASH>
<HASH>
TxId TxType Sender Recipient Payload
… … … … …
… … … … …
Previous Block
Merkle Root
<HASH>
<HASH>
TxId TxType Sender Recipient Payload
… … … … …
… … … … …
… … … … …
Previous Block
Merkle Root
<HASH>
<HASH>

11. BLOCKCHAIN BASICS
BASIC SECURITY CONCEPTS
▸ asymmetric key cryptography (RSA, Curve25519, …)
▸ cryptographic hash functions (SHA, SCRYPT, …)
▸ public-/private key
▸ verify/sign transactions

12. BLOCKCHAIN BASICS
SECURE TRANSACTIONS
TxId TxType Sender Recipient Payload Sender Signature
<HASH> Asset-Transfer <PUBLIC KEY> <PUBLIC KEY> 10 <SIGNATURE>
<HASH> Private Msg <PUBLIC KEY> <PUBLIC KEY> <CIPHERTEXT> <SIGNATURE>
<HASH> Public Msg <PUBLIC KEY> <PUBLIC KEY> Hey Dude! <SIGNATURE>
<HASH> Arbitrary Data <PUBLIC KEY> <PUBLIC KEY> <BLOB> <SIGNATURE>

13. BLOCK GENERATION
TRANSACTION BROADCAST
TxId TxType Sender Recipient Payload Sender Signature
#1 Asset-Transfer <PUBLIC KEY> <PUBLIC KEY> 10 <SIGNATURE>
#2 Private Msg <PUBLIC KEY> <PUBLIC KEY> <CIPHERTEXT> <SIGNATURE>
#3 Public Msg <PUBLIC KEY> <PUBLIC KEY> Hey Dude! <SIGNATURE>
Tx #1
Tx #3
Tx #2
unconfirmed transactions

14. BLOCK GENERATION
MINING

15. BLOCK GENERATION
PROOF OF WORK
▸ based on the computing power
(hashrate)
▸ may lead to centralisation (mining
pools, asic manufactures)
▸ waste of energy

16. BLOCK GENERATION
BLOCK TEMPLATE
TxId TxType TxFee Sender Recipient Payload
<HASH> Asset-Transfer 3 Account A Account B 10
<HASH> Asset-Transfer 1 Account B Account C 5
<HASH> Asset-Transfer 1 Account A Account C 5
<HASH> Asset-Transfer 5 Account C Account A 10
Merkle Root
Previous Block
cc0d7e487c44bb1f28e83a15b0f1c4507499
001f2844e83a15b0f1c4507499cc0d7e487c
TransactionsHeader
Nonce ????

17. BLOCK GENERATION
HASHCASH
Merkle Root
Previous Block
cc0d7e487c44bb1f28e83a15b0f1c4507499
001f2844e83a15b0f1c4507499cc0d7e487c
Header
Nonce ????
Block Hash <HASH>(HEADER)
Difficulty 32 (0000xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
#1 (nonce=100) <HASH>(HEADER) = 87c44bb1f28e83a15b0f1c4507499cc0d7e4
#2 (nonce=101) <HASH>(HEADER) = 3a15b0f1c4507499cc0d7e487c44bb1f28e8
#3 (nonce=102) <HASH>(HEADER) = 00c0d7e487c44bb1f28e83a15b0f1c450749
#4 (nonce=103) <HASH>(HEADER) = 0000b1f28e83d7e487c4f1c4507494ba15b0

18. BLOCK GENERATION
PROOF OF STAKE
▸ based on the amount of stake (tokens)
▸ still unsolved issues (nothing at stake)
▸ almost anyone (with low computing power) can
participate

19. BLOCK GENERATION
NEW BLOCK BROADCAST
▸ new block will be broadcasted
▸ the “best” block/chain (highest difficulty) wins
▸ generator gets rewarded (eg. transaction fees and/or
new tokens)

20. CONSENSUS AND SECURITY CONSIDERATIONS
CONSENSUS
▸ code is law
▸ build-in (peers, smart contracts, …)
▸ no central authority (admin, government, …)
▸ majority rules
▸ different consensus rules may lead to a fork (split)
of the blockchain

21. CONSENSUS AND SECURITY CONSIDERATIONS
ATTACK VECTORS
▸ 51% attack
▸ prevent transactions of gaining confirmations
▸ reverse transactions
▸ double spends
▸ nothing at stake (PoS)

22. DECENTRALISED APPLICATIONS (ÐAPPS)
ETHEREUM
▸ White-paper 2013 by Vitalik Buterin
▸ Yellow-paper 2014 by Garvin Wood
▸ Swiss based non-profit Ethereum foundation
▸ Crowd-funded
▸ Roadmap
▸ July 2015 “Ethereum Frontier”
▸ March 2016 “Ethereum Homestead”
▸ “Metropolis” & “Serenity”
Source: www.ethereum.org

23. DECENTRALISED APPLICATIONS (ÐAPPS)
ETHEREUM VIRTUAL MACHINE (EVM)
▸ “the world computer” (Gavin Wood)
▸ is a global sigleton
▸ is always running
▸ cannot be shut down, stopped or censored
▸ turing complete scripting language (Solidity)
▸ guaranteed atomicity, synchrony, provenance
▸ completely isolated runtime environment for smart
contracts
Source: www.ethereum.org

24. DECENTRALISED APPLICATIONS (ÐAPPS)
SMART CONTRACTS
▸ address is derived from the creator address
▸ need “gas” to run transactions
▸ can call other contracts
▸ dynamically load code from a different address (“delegatecall”)
▸ send Ether to non-contract accounts
▸ create other contracts
Source: www.ethereum.org

25. DECENTRALISED APPLICATIONS (ÐAPPS)
DEVELOPMENT
▸ Mix IDE (discontinued in favor for remix)
▸ Alethzero (discontinued in favor for remix)
▸ remix (early alpha)
▸ Visual Studio Code
▸ Ethereum JavaScript console