Public Blockchain Scalability (April 2018)
•Download as PPTX, PDF•
1 like•1,208 views
This document discusses blockchain scalability and various solutions that have been proposed or implemented to increase transaction throughput. It begins by defining scalability as the number of transactions a system can process per unit of time. It then discusses limitations of the basic public blockchain model using Bitcoin as an example. The remainder of the document explores potential scalability solutions such as increasing block sizes, segregated witness, sharding, state channels, payment networks like Lightning and Raiden, alternative consensus mechanisms like proof-of-stake, and approaches beyond blockchains like directed acyclic graphs.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Public Blockchain Scalability (April 2018)
Similar to Public Blockchain Scalability (April 2018) (20)
Recently uploaded
Recently uploaded (20)
Public Blockchain Scalability (April 2018)
- 1. Public Blockchain Scalability Casey Caruso - Engineer @ Google 4/22/18 @caseykcaruso
- 2. The number of transactions per unit of time that the system can process. What is Scalability? @caseykcaruso
- 6. Transactions Per Second 157 2000 @caseykcaruso
- 7. The long-term goal is for the platform to be able to process transactions “at Visa- scale transaction levels” - Vitalik Buterin @caseykcaruso
- 8. How does the public blockchain work today? @caseykcaruso
- 10. Blockchain PREV HASHPREV HASHPREV HASH @caseykcaruso
- 11. Blockchain TRANSACTION TRANSACTION PREV HASH TRANSACTION TRANSACTION TRANSACTION PREV HASH TRANSACTION TRANSACTION TRANSACTION PREV HASH @caseykcaruso
- 12. Consensus Mechanism for all participants to reach agreement about the truth of the data @caseykcaruso
- 13. Bitcoin Proof of Work (PoW) Consensus All miners work to solve 1 puzzle at a time A puzzle is solved every 10 minutes The probability of a mining a block is dependent on computational work that is done by a miner @caseykcaruso
- 14. MEM POOL Bitcoin Proof of Work (PoW) Consensus MINER A MINER B MINER C @caseykcaruso
- 15. Bitcoin Proof of Work (PoW) Consensus MINER A BLOCK TRANSACTION TRANSACTION TRANSACTION MINER B BLOCK TRANSACTION TRANSACTION MINER C BLOCK TRANSACTION TRANSACTION TRANSACTION @caseykcaruso
- 16. Bitcoin Proof of Work (PoW) Consensus MINER A BLOCK TRANSACTIONS MINER C BLOCKMINER B BLOCK HASH ( ) = 000x NONCE GUESS TRANSACTIONS HASH ( ) = 000x NONCE GUESS TRANSACTIONS HASH ( ) = 000x NONCE GUESS @caseykcaruso
- 18. It takes a lot of work and time to process a transaction. @caseykcaruso
- 20. Why don’t we make bigger blocks? @caseykcaruso
- 21. Block Size Increase 1 MB 8 MB @caseykcaruso
- 22. Is there anything we can take out of each block? @caseykcaruso
- 23. Segregated Witness (SegWit) TRANSACTION INPUTS SIGNATURES OUTPUTS STUFF OTHER STUFF MORE STUFF @caseykcaruso
- 24. Segregated Witness (SegWit) TRANSACTION INPUTS OUTPUTS OTHER STUFF MORE STUFF SIGNATURES STUFF @caseykcaruso
- 25. Input: Previous txid: f5d...9a6 Index: 0 scriptSig: 304...501 Output: Value: 5000000 scriptPubKey: … OP_CHECKSIG Segregated Witness (SegWit) Transaction Before SegWit @caseykcaruso
- 26. Input: Previous txid: f5d...9a6 Index: 0 scriptSig: (empty) Output: Value: 5000000 scriptPubKey: … OP_CHECKSIG Segregated Witness (SegWit) Transaction Before SegWit Transaction After SegWit Input: Previous txid: f5d...9a6 Index: 0 scriptSig: 304...501 Output: Value: 5000000 scriptPubKey: … OP_CHECKSIG Witness data: Input 0 scriptSig: 304...501 @caseykcaruso
- 27. Do we all have to process all transactions? @caseykcaruso
- 28. Layer 1 Onchain Sharding BLOCKCHAIN SHARDING @caseykcaruso
- 31. Onchain Sharding 0x8 TRANSACTIONS GROUP 1 GROUP 2 0x9 TRANSACTIONS @caseykcaruso
- 32. What about doing things offchain? @caseykcaruso
- 33. Layer 2 Offchain State Channels BLOCKCHAIN STATE CHANNEL @caseykcaruso
- 34. Offchain Payment Channels Move processes off-chain, while still retaining a blockchain’s trustworthiness. BLOCKCHAIN BOB COFFEE SHOPIOU @caseykcaruso
- 35. Lightning Payment Network For BTC Payment Channel On Mainnet @caseykcaruso
- 37. Lightning Payment Network TX BALANCE Bob: .05 BTC Shop: 0 BTC S TX BALANCE Bob: .05 BTC Shop: 0 BTC B @caseykcaruso
- 39. Lightning Payment Network @caseykcaruso TX BALANCE Bob: .049 BTC Shop: .001 BTC S TX BALANCE Bob: .049 BTC Shop: .001 BTC B
- 40. Lightning Payment Network @caseykcaruso Coffee On-chain Bob Shop 1st No .049 BTC .001 BTC 2nd No .048 BTC .002 BTC 3rd No .047 BTC .003 BTC … 50th Yes 0 BTC .05 BTC
- 41. Lightning Payment Network @caseykcaruso TX BALANCE Bob: 0 BTC Shop: .05 BTC S TX BALANCE Bob: 0 BTC Shop: .05 BTC B
- 42. Lightning Payment Network TX Bob: 0 BTC Shop: .05 BTC B S @caseykcaruso
- 44. Lightning Hashed Timelock Contract (HTLC) DAVEALICE BOB CAROL @caseykcaruso
- 45. Lightning Hashed Timelock Contract (HTLC) DAVE R, h(R) ALICE h(R) BOB CAROL @caseykcaruso
- 46. Lightning Hashed Timelock Contract (HTLC) DAVE R, h(R) ALICE h(R) BOB CAROL STEP 1: 3 DAY LOCK STEP 2: 2 DAY LOCK STEP 3: 1 DAY LOCK @caseykcaruso
- 47. Raiden Payment Network @caseykcaruso ERC 20 Lightning for Ethereum, aka all ERC20 tokens.
- 48. Can we do more than payments offchain? @caseykcaruso
- 49. Plasma Protocol ROOT CHAIN (ETHEREUM) PLASMA CONTRACT (PRIVATE BLOCKCHAIN) PLASMA CONTRACT (DECENTRALIZED EXCHANGE) PLASMA CONTRACT (MICROPAYMENTS) PLASMA CONTRACT (SOCIAL NETWORK) @caseykcaruso
- 50. It’s still a lot of work. What about reaching consensus a different way? @caseykcaruso
- 51. Proof of Stake (PoS) Consensus All nodes who want to validate blocks must stake a minimum amount The probability of validating a block is dependent on your stake and the age of your stake @caseykcaruso
- 52. Proof of Stake (PoS) Consensus VALIDATOR A TRANSACTION TRANSACTION TRANSACTION VALIDATOR B TRANSACTION TRANSACTION VALIDATOR C TRANSACTION TRANSACTION TRANSACTION @caseykcaruso
- 53. VALIDATOR A VALIDATOR CVALIDATOR B STAKED AMOUNT STAKED AMOUNT STAKED AMOUNT Proof of Stake (PoS) Consensus @caseykcaruso
- 54. Ethereum’s Casper PoS Protocol Bonded Stake Min Stake 1000 ETH Non delegated PoS @caseykcaruso
- 55. What about not using a blockchain at all? @caseykcaruso
- 56. Directed Acyclic Graphs (DAGs) A B C D E F @caseykcaruso
- 57. Directed Acyclic Graphs (DAGs) In dev mode No miners or blocks Scales as nodes are added @caseykcaruso
- 58. Things I didn’t cover ● The Byzantine Generals problem ● Practical Byzantine Fault Tolerant Alternative Algorithms ● SegWit 2x ● Sharding ● Federated Byzantine agreements ○ Stellar’s public algorithm ○ Ripple’s private algorithm ● Tendermint’s BPoS algorithm ● DPOS systems in depth @caseykcaruso
Editor's Notes
- Show of hands - who is technical? Goal is to explain the evolution of public blockchain scalability
- There are a lot of ways to define scalability so for the purposes of the conversation let’s define it as “”
- Bitcoin, the most used blockchain can handle 7 https://altcointoday.com/bitcoin-ethereum-vs-visa-paypal-transactions-per-second/
- Ethereum the second most popular blockchain can handle 20 https://altcointoday.com/bitcoin-ethereum-vs-visa-paypal-transactions-per-second/
- Ethereum the second most popular blockchain can handle 20 https://altcointoday.com/bitcoin-ethereum-vs-visa-paypal-transactions-per-second/
- People may think ethereum and visa are not similar solutions but vitalik himself said to long-term goal is visa-scale so how are we going to get there
- the Blockchain is a sequence of blocks
- Each block is cryptographically linked to the previous block by references the previous block’s hash Blockchain is a linked list
- Each block is full of transactions and 1 MB in size
- In order to add the next block, we need consensus Consensus is used to make sure all nodes know which block is next and have a updated version of the blockchain
- At a high level ---
- Now this is how this actually works - unverified transactions taken from mem pool Miners - which are computers running special software
- Miners build up blocks of transactions
- This is the puzzle solving step Miners start guessing a nonce, which is a random number, in hopes that the hash of the transactions + the nonce equal a certain output Every miner is trying to get the same output Finding a nonce that equals such output takes about 10 minutes and is the main bottleneck of this system Costly and long process Once a miner guesses correctly they broadcast to the network and sends to full nodes - a full nodes verify Full nodes download every block and transaction and check them against Bitcoin's consensus rules. Light nodes don’t store the whole blockchain - they query full nodes Full nodes store the whole blockchain Miners can connect and trust full nodes
- So PoW is very secure and decentralized but its not very scalable It’s often debated what we should be optimizing for in a consensus alg. Bitcoin core devs want to optimize for the decentralization Newer kids on the block, like stellar, want to optimize for scalability and forgo decentralization. In general, most scalability solutions can’t obtain all three of these aspects - so we call it the scaling trilemma We have Scalability - being able to process x transactions Security - being secure against x% attackers Decentralization - system being able to run where each participant only has access to x resources
- If blocks take so much work and time to make, logically the first question is... Why don’t we make the blocks bigger so we can fit more transactions in each block?
- In 2010, Satoshi introduced a block size limit of 1 MB (hidden in two commits) One of the biggest cons is centralization - As the block size increases, it becomes more expensive and more difficult to operate a full node because of the data storage and bandwidth required so you are essentially limiting who can participate Bitcoin cash ended up doing a hard fork and now has 8MB blocks OLD on a subset computer that can handle such large computations This will be not only challenging data storage, but might actually be beyond the bandwidth capacity/datacap of some full node maintainers. On
- If we can't make it bigger, is there anything we can take out so more transactions can fit?
- Solution called segwit v1 was activated last year, soft fork Look at whats in a transaction the digital signature accounted for 60% of the transactions So segwit says - lets take the signatures out since only needed at validation
- Signatures get moved
- Looking at some pseudo code here - we see the digital signature (`scriptSig`) in the input section
- With segwit, we take that scriptsig out and move it away Note that only white boxes count towards the block size so this frees up more space Even more importantly segwit makes the tx-id independent from the signature which fixes something called the malleability bug This makes doing payment channels a lot easier
- After we optimized what was in a block by looking at the transaction, we thought more about transactions and specifically questioned why everyone is looking at every transaction. Could we divide and conquer?
- This is called a layer 1 solution - because it is implemented at the base-level protocol of ethereum itself
- sharding the blockchain requires us to create a network where every node only processes a small portion of all transactions Allowing miners or validators to work in parellel
- sharding the blockchain requires us to create a network where every node only processes a small portion of all transactions Allowing miners or validators to work in parellel
- Implementation varies but one way this could work is by having all transactions that end in 8 route to one group all transactions ending in 9 to another This solution looks promising, Shard communication is difficult but all in all this solution will definitely be implemented in the future
- Zooming out, away from transactions and blocks, thinking about the chain - is there a way we could do stuff offchain? Can we transact off the blockchain?
- Layer 2 solutions - solutions are built “on top of” the main-chains
- Let’s say bob goes to the same coffee shop every day, putting that coffee transaction on the blockchain every day really is overkill (especially with fees) So the thought here is let’s do those transactions off the blockchain It can be thought of as a set of IOUs or a bar tab between two people and then you use setlle on chain as needed
- Want to talk about lightning, at a high level Lightning just works for BTC But it's one of the only solution Payment channel that is on mainnet and it really works Huge fan of lightning Just for payments
- The first step in the lightning network process is both parties depositing, or locking up, a certain amount amount This is a called a funding transaction and happens onchain
- Exchange coffee
- Called a commitment transaction
- Exchange coffee
- Called a commitment transaction
- The most updated balance is put on the blockchain as a transaction
- routing
- Let’s say alice wants to pay dave and she is going to go through bob and carol In order to allow for multiple hops you need a Hashed Timelock contract (HTLC)
- Dave, the recipient, creates “pre-image” R, hashes R, and passes H(R) to alice
- The number of hops is then calculated and deprecating HTLCs are set between each party Carol asks Dave if he knows R, Dave has 1 day to show Carol he knows R, Carol has then one more day to show Bob and one more day to show alice
- Same thing for this discussion but of course it will be possible will all erc20 tokens
- We are very happy with the promise of payment channels so how about extending this to more than payments? So increasing blocks, changing blocks, doing things offchain, Layer 2 solution still , built “on top of” the ethereum main-chain.
- Plasma is a protocol of smart contracts that can be used on top of a root blockchain, such as Ethereum, to create sidechains Aims to scale transactions by creating nestable side chains that only interact with the main chain every once in a while Cons Merging children chains is still in development Still in development 51% attack, through PoW is more possible because there is more compute power for each child chain which then can affect the whole chain .
- Even if we make bigger blocks, optimize the blocks, do things offchain, we still need to settle on chain and THAT is still a bottleneck Can we reach consnenus in a different way?
- At a high level --- replace the hash function calculation with a simple digital signature which proves ownership of the stake. the creator of a new block is chosen in a deterministic way, depending on its wealth
- Min stake which reduces num of validators Bonded to solve “nothing at stake problem” Non-delagated - but some want delegated to prevent the rich from getting richer
- Final question - what about not using a block at all
- Directed, no loops and it’s a web