Blockchan For Developers

135 views

Published on

Slides for the talk given at CodeFreeze Meetup, Dec 2016, Saint-Petersburg

Published in: Engineering
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
135
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Blockchan For Developers

  1. 1. CodeFreeze Meetup, Dec `16 Blockchain For Developers Alexander Chepurnoy (aka kushti) @chepurnoy IOHK Research
  2. 2. Background ● Nxt core developer ● smartcontract.com cofounder (left) ● Scorex since late 2014 ● IOHK Research
  3. 3. The talk is about ● How a developer can view a blockchain system ● What are open problems in blockchains
  4. 4. Blockchain ● Public append-log ● Readable by all ● Writeable by all ● Tamper-resistant ● Authenticated content
  5. 5. Use Cases ● E-Cash ● Titles ● Stocks settlement
  6. 6. Digital Signature ● generate(seed): PublicKey → PrivateKey ● sign(message, privateKey): Signature ● verify(publicKey, signature, message): Boolean We assume a scheme doesn't allow to get a signature for a new message using old message→signature pairs Examples: RSA, ECDSA, EdDSA
  7. 7. Cryptographic Hash Function hash(preimage) → value ● arbitrary-sized preimage ● fixed-sized random output ● Infeasible to find a preimage or a collision
  8. 8. Merkle Tree
  9. 9. Background: E-Cash ● Alice is sending a coin to Bob ● A coin is just a bitstring ● How to prevent double-spend? ● How to make money transfers untrackable?
  10. 10. Background: E-Cash ● David Chaum, mid-1980s ● E-Cash ● Anonymous ● Central Bank required ● DigiCash (bankruptcy in 1998) ● a lot of academic research (not turned out to be practical)
  11. 11. Distributed Consensus ● Fixed number of known parties ● 0/1 inputs Properties: ● Agreement – all the parties agree on the same output ● Validity – an output must be some node's input ● Termination – the protocol somewhen finishes
  12. 12. Failure Models ● Crash-Stop ● Crash-Recovery ● Byzantine – arbitrary behaviour
  13. 13. Impossibility Results ● FLP theorem (Fischer et al, 1983) – a deterministic consensus protocol doesn't have a guarantee of termination in case of asynchronous messaging and a possibility of a single node to fail ● Byzantine Generals problem - it there are t Byzantine parties amongst n, agreement is possible only if n > 3t and the communication is synchronous (bounded delay)
  14. 14. Environment ● P2P network ● No central party ● Many parties are possibly malicious ● Probabilistic broadcast
  15. 15. P2P network ● Each node has own view ● The goal is to have replicated subset of it across the network ● In the presence of Byzantine adversaries! ● (so only honest nodes agree on the state) ● (and only eventually)
  16. 16. A transaction ● Atomic state modifier ● Authenticated
  17. 17. Minimal State ● Can answer the question „whether a transaction is valid and so applicable“ ● apply(min_state, tx): (MinimalState | Error) ● apply(apply(min_state, tx), tx) is always Error ● In Bitcoin UTXO set
  18. 18. Minimal State ● Transaction application is deterministic ● There's some initial (genesis) state hardcoded ● By applying the same sequence of transactions to the genesis state, two honest nodes got the same minimal state ● Thus we need for a guarantee every pair of honest nodes is eventually applying the same sequence of transactions!
  19. 19. Blockchain ● Transactions packed into blocks ● Blocks are linked
  20. 20. Blockchain
  21. 21. Block Generator Election ● random party ● sybil-resistant ● efficient (min communication) solution ● each party has limited queries to an oracle function ● random oracle answers „yes“ with adjustable probability ● replace random oracle with a hash function
  22. 22. Block Header 02000000b6ff0b1b1680a2862a30ca44d346d9e8910d334beb48ca0 c00000000000000009d10aa52ee949386ca9385695f04ede270dd a20810decd12bc9b048aaab3147124d95a5430c31b18fe9f0864 ● version (2) ● hash of a previous header ● Merkle root hash of transactions ● timestamp ● target ● nonce
  23. 23. Bitcoin's Proof-of-Work ● hash(blockheader) < target ● target = 1 / difficulty ● difficulty recalculated every M blocks ● difficulty Di = Di-1 * M * texp / Tobserved ● texp = 10 minutes ● M = 2016
  24. 24. Rewards ● Why to perform work? ● Miner creates a transaction to self with a fixed amount ● This is the 1st transaction in the Merkle tree (coinbase tx)
  25. 25. Race For a Block ● Everyone can participate ● Chance to win is hashpower(mine) / hashpower(total) (well, not really) ● Collisions are possible (two blocks at about same time) ● Eventually longest chain wins (well, not really)
  26. 26. Break! ● Questions?
  27. 27. GKL Model ● „The Bitcoin Backbone Protocol:Analysis and Applications“ by Garay / Kiayias / Leonardos ● slides: https://bitcoinschool.gr/slides/session2.pdf Bitcoin consensus protocol properties: ● Common Prefix ● Chain Quality ● Chain Growth
  28. 28. Common Prefix no matter the strategy of the adversary, the chains of two honest parties will fork in the last k blocks with probability exponentially decreasing with k
  29. 29. Chain Quality any sequence of blocks in an honest party’s chain will contain some number of honest blocks with overwhelming probability
  30. 30. Chain Growth honest party's chain grows with some minimal pace with an overwhelming probability
  31. 31. Bitcoin ● digital cash ● transaction is a set of token transfers
  32. 32. Bitcoin: Transaction
  33. 33. Bitcoin Script output: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG input: <sig> <pubKey>
  34. 34. Bitcoin Addresses ● There are no any accounts in Bitcoin ● In most cases address is PKH (160 bits) + checksum + additional info, in Base58 encoding
  35. 35. Bitcoin: UTXO set ● unspent outputs set ● enough to validate any transaction ● application is about removing outputs spent and add new ones
  36. 36. Memory Pool ● contains unconfirmed transaction ● inconsistent across a network
  37. 37. Vault (Wallet) ● node-specific information ● e.g. transactions for selected pubkeys
  38. 38. Node view (MinimalState, Blockchain, MemoryPool, Wallet) (MinimalState, Blockchain) is eventually the same for all the honest nodes
  39. 39. What app developer should know ● Rollbacks are possible! ● Transaction is always visible before inclusion ● Frontrunning / replay attacks ● Signature and transaction malleability
  40. 40. Modifications ● alternative consensus protocols (Proof-of-Stake etc) ● richer transactional models (NameCoin, Ethereum, ZCash) ● alternative log structures (Bitcoin-NG, GHOST, TwinsChain) ● incentivization of certain activities (Permacoin, Rollerchain)
  41. 41. Scalability
  42. 42. Basic assumption ● It should be possible to run a fullnode on a commodity hardware ● HDD ● 1-2 GB RAM ● 1 Mbps at most ● Ethereum lost ● Bitcoin is doing hard to hold the assumption
  43. 43. Bitcoin's Troughput (TPS) ● 7 ??? no ● 2-3 in fact ● 1/600 in worse case https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_trans
  44. 44. Better throughput ● Bitcoin-NG ● GHOST/SPECTRE
  45. 45. Blockchain Pruning
  46. 46. Rollerchain ● Chepurnoy, Larangeira, Ozhiganov http://arxiv.org/abs/1603.07926 „Rollerchain, a Blockchain Secure in the Rational Storage Setting“
  47. 47. Rollerchain ● Only last n full blocks to be stored collectively and n state snapshots ● Each miner stores k state snapshots
  48. 48. Rollerchain ● New node can download a historical snapshot ● Fullblocks not needed for mining could be thrown away ● Blockheaders are to be stored forever, so must be small
  49. 49. Unload the chain ● Move things off-chain ● Sidechains ● Avoid all the transactions execution(RsCoin)
  50. 50. Offchain ● Lightning Network ● Offchain contracts(SMC/SMP)
  51. 51. Smart Contracts ● Ethereum isn't scalable ● Hawk ● Enigma
  52. 52. Dark side of a public blockchain
  53. 53. Slowing down processing ● Bitcoin: CVE-2013-2293 (fetching outputs from hdd) ● Ethereum: most of recent attacks (fetching account states)
  54. 54. Asymmetric schemes ● Not neccessary to hold the whole state ● Full security guarantees ● Reyzin, Meshkov, Chepurnoy, Ivanov „Improving Authenticated Dynamic Dictionaries, with Applications to Cryptocurrencies“ https://eprint.iacr.org/2016/994
  55. 55. Asymmetric vs Symmetric
  56. 56. AVL+ trees vs Ethereum‘s tries
  57. 57. Rational Behaviour ● Why store blocks for years after processing? ● Why to validate blocks (in PoW)? ● Why to work on a single chain (in PoS)?
  58. 58. Validationless (SPV) mining ● Start to mine on a header ● Trust other nodes regarding transactions ● https://bitcoin.org/en/alert/2015-07-04-spv-mining - 6 blocks starting with an invalid one
  59. 59. If no block reward Carlsten, Kalodner, Weinberg, Narayan „On the Instability of Bitcoin Without the Block Reward“ http://randomwalker.info/publications/mining_CCS.pdf
  60. 60. Advices ● Don‘t roll your own crypto ● Don‘t roll own blockchain
  61. 61. Scorex ● Scorex ● Utterly abstract (no even a blockchain in the bottom) ● GitHub https://github.com/ScorexFoundation/Scorex ● Manual (not fully ready): https://github.com/ScorexFoundation/ScorexTutorial
  62. 62. Scorex
  63. 63. Questions? Twitter: @chepurnoy Mail: kushti@protonmail.ch

×