Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Blockchain For Developers

720 views

Published on

Slides for the talk given @ Blockchain Hackathon Moscow (Nov '16)

Published in: Engineering
  • Hello! I can recommend a site that has helped me. It's called ⇒ www.HelpWriting.net ⇐ So make sure to check it out!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • If u need a hand in making your writing assignments - visit ⇒ www.HelpWriting.net ⇐ for more detailed information.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! I have searched hard to find a reliable and best research paper writing service and finally i got a good option for my needs as ⇒ www.WritePaper.info ⇐
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Blockchain For Developers

  1. 1. Blockchain Hackathon, Nov `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. Environment ● P2P network ● No central party ● Probabilistic broadcast
  5. 5. 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)
  6. 6. A transaction ● Atomic state modifier ● Authenticated
  7. 7. 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
  8. 8. 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!
  9. 9. Blockchain ● Transactions packed into blocks ● Blocks are linked
  10. 10. Blockchain
  11. 11. Block Generator Election ● random party ● sybil-resistant ● efficient(min communication) solution ● each party has limited queries to random oracle ● random oracle answers „yes“ with adjustable probability ● replace random oracle with a hash function
  12. 12. Bitcoin's Proof-of-Work ● hash(blockheader) < target ● target T = 1 / difficulty
  13. 13. 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
  14. 14. 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
  15. 15. Chain Quality any sequence of blocks in an honest party’s chain will contain some number of honest blocks with overwhelming probability
  16. 16. Chain Growth honest party's chain grows with some minimal pace with an overwhelming probability
  17. 17. Bitcoin ● digital cash ● transaction is a set of token transfers
  18. 18. Bitcoin: Transaction
  19. 19. Bitcoin Script output: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG input: <sig> <pubKey>
  20. 20. Bitcoin: UTXO set ● unspent outputs set ● enough to validate any transaction ● application is about removing outputs spent and add new ones
  21. 21. Memory Pool ● contains unconfirmed transaction ● inconsistent across a network
  22. 22. Vault (Wallet) ● node-specific information ● e.g. transactions for selected pubkeys
  23. 23. Node view (MinimalState, Blockchain, MemoryPool, Wallet) (MinimalState, Blockchain) is eventually the same for all the honest nodes
  24. 24. What app developer should know ● Rollbacks are possible! ● Transaction is always visible before inclusion ● Frontrunning / replay attacks ● Malleability
  25. 25. 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)
  26. 26. Scalability
  27. 27. Bitcoin's Troughput (TPS) ● 7 ??? no ● 2-3 in fact ● 1/600 in worse case https://www.reddit.com/r/Bitcoin/comments/3cgft7/large st_transaction_ever_mined_999657_kb_consumes/
  28. 28. 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
  29. 29. Better throughput ● Bitcoin-NG ● GHOST/SPECTRE
  30. 30. Blockchain Pruning
  31. 31. Rollerchain ● Chepurnoy, Larangeira, Ozhiganov http://arxiv.org/abs/1603.07926 „Rollerchain, a Blockchain With Safely Pruneable Full Blocks“
  32. 32. Rollerchain ● Only last n full blocks to be stored collectively and n state snapshots ● Each miner stores k state snapshots
  33. 33. 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
  34. 34. Unload the chain ● Move things off-chain ● Sidechains ● Avoid all the transactions execution(RsCoin)
  35. 35. Offchain ● Lightning Network ● Offchain contracts(SMC/SMP)
  36. 36. Smart Contracts ● Ethereum isn't scalable ● Hawk ● Enigma
  37. 37. Dark side of an open blockchain
  38. 38. Slowing down processing ● Bitcoin: CVE-2013-2293 (fetching outputs from hdd) ● Ethereum: most of recent attacks (fetching account states)
  39. 39. 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
  40. 40. Asymmetric vs Symmetric
  41. 41. AVL+ trees vs Ethereum‘s tries
  42. 42. Rational Behaviour ● Why store blocks for years after processing? ● Why to validate blocks (in PoW)? ● Why to work on a single chain (in PoS)?
  43. 43. 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
  44. 44. If no block reward Carlsten, Kalodner, Weinberg, Narayan „On the Instability of Bitcoin Without the Block Reward“ http://randomwalker.info/publications/mining_CCS.pdf
  45. 45. Questions? Twitter: @chepurnoy Mail: kushti@protonmail.ch

×