Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Philly Ethereum Meetup - Speaker's Notes

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers. →

Philly Ethereum Meetup - Speaker's Notes

Avatar for Thomas Jay Rush

Thomas Jay Rush

April 16, 2018

Other Decks in Technology

Transcript

  1. Talk Outline - Introduction to Consensus Algorithms - Proof of

    Work: Overview and Issues - Naive Proof of Stake: Even More Issues - Security Deposit Proof of Stake - Current Ethereum PoS Research
  2. Consensus Protocols Consensus protocols allow nodes on a distributed network

    to make consistent decisions given mutually exclusive possibilities. For example, if we are “coming to consensus on a bit”, then the goal of a consensus protocol is to have nodes all output “0” or all output “1.” We can come to consensus on more interesting things than a 0/1, like an ordered list of transactions (why they are interesting).
  3. Consensus Protocols We want our consensus protocol to have safety

    and liveness. Safety: if (protocol-following) nodes do decide on values, then they will decide on values that do not conflict. Liveness: any (protocol-following) node will eventually make a decision that accepts or rejects any given value.
  4. Consensus Protocols Fundamentally, consensus is a hard problem because messages

    may be delayed, lost, or delivered out of order. Furthermore, nodes might crash, lie, or otherwise act arbitrarily. Ideally, we want to preserve safety and liveness in the worst conditions we can (though in some cases it’s impossible).
  5. PoW as Consensus Pt. 1 Fundamentally, it’s very important that

    different nodes agree on the same blockchain - which is why blockchains use consensus algorithms. Proof of work is the most basic and popular consensus algorithm for public blockchains. Essentially: do lots of hashing (aka, spend money) to create a block, and only get paid back if it makes the main chain. So, incentive to converge on a single chain (else you lose money!).
  6. PoW as Consensus Pt. 2 Safety: we want all nodes

    to not think that different blockchains are the real blockchains (so PoW makes it expensive to make multiple chains). Liveness: we want the blockchain to actually be built (otherwise, the blockchain wouldn’t be to interesting).
  7. Issues with PoW - Energy usage - Using as much

    electricity as a small country :( - Expensive - Millions of dollars a day in block rewards - Large economies of scale - Mining farms get higher return than hobbyist - Incentives for cartels to form - 51% attacks are free if successful, censorship increases profits, selfish mining, etc.
  8. Proof of Stake (PoS) has been a proposed solution to

    these problems for quite some time.
  9. In PoW, your “power” is the amount of computing power

    you have. In PoS, the “power” is the amount of coins you have.
  10. Naive Proof of Stake Example: 1. Take the previous block

    hash (or some random number), and hash it with the address that holds your coins. 2. If the resulting hash is less than some constant * num_coins you hold in address, you can make a block. The more coins you have, the higher the chance you will be able to make a block (just like computing power and PoW).
  11. PoW

  12. Security-deposit PoS - Security deposits - So you can’t move

    your money - Slashing conditions (enter traditional consensus literature) - So you lose money if you build on both forks - Examples: - Casper(s), Tendermint - Not Examples: - Ouroboros, DPoS, all naive PoS
  13. Finality in Security Deposit Based PoS Tendermint, Casper, and all

    current security-deposit PoS protocols give nodes the ability to detect something called “finality.” Blocks are “finalized” when nodes can detect that they will always be in the main chain. Essentially, based on the messages that validators/miners have sent, nodes can detect that these validators/miners will never be able to switch to different blocks. This is not possible in PoW, as blocks are only probabilistically finalized (and can always be reverted in the future if a higher-weight chain shows up).
  14. Casper(s) Casper is a family of consensus protocols that have

    been worked on by folks in the Ethereum Research team for the past couple years. All Casper protocols are security deposit based PoS protocols. There are two main branches of Casper research: - Casper the Friendly Finality Gadget (Casper FFG) - Correct-by-construction Casper (CBC Casper) Sorry for the confusing names! :D
  15. Casper the Friendly Finality Gadget A stepping stone to full

    PoS, this is a hybrid PoS/PoW system than can be overlayed over the main Ethereum chain. Based on the older academic literature about BFT consensus algorithms, although it is massively simplified. Traditional literature is both incredibly rigourous and very complicated.
  16. Casper the Friendly Finality Gadget 1. Make a deposit to

    become a validator. 2. Create blocks through some pseudo-random (or not) process. 3. Every epoch (50 blocks), create messages called votes, that clients can then use to detect finality. a. You send these votes as transactions that get put on the blockchain. 4. If you create two conflicting votes, then your deposits can be slashed. a. How do we know when two votes are conflicting? 5. After starting withdraw process, have to wait some time (4 months) until you can move your deposit.
  17. Conflicting Votes 2 different votes conflict if: - They are

    sent during the same epoch - They lie about “what they’ve seen in the past.” For time reasons, I’m going to leave out the safety proof and the exact structure of the messages. See it here: tinyurl.com/current-casper
  18. Casper FFG More notes: - You can only be slashed

    if you are inconsistent with yourself Aka: no one can trick you into getting slashed! - If there is a successful attack (two chains are finalized), then at least ⅓ of validators must have broken the rules, and can be slashed. Aka: slashing conditions and security deposits solve the nothing at stake problem. Validators can’t build on both chains, or they lose their deposits.
  19. Weak Subjectivity After withdrawing, validators can lie with their old

    key (we can’t slash them!). Therefore, these validators can make up alternate versions of history (or sell their keys for someone else to do this). This is called a “long-range attack,” and the only solution is an added assumption called “weak subjectivity.”
  20. Weak Subjectivity Upon first sync, users must have a “recent”

    blockhash (within the withdrawal period). Thus, they can get economically-meaningful signatures from bonded validators. This is likely the largest change in security assumptions between PoW and PoS. However, for most users, nothing will change. Clients update on this time scale as well.
  21. CBC Casper vs. Casper FFG CBC Casper is the other

    main branch of Ethereum PoS research. It’s a method for generating consensus protocols, as well as a family of consensus protocols, rather than a single protocol (like Casper FFG). One of the protocols is Casper the Friendly GHOST, which is easily adapted as a PoS protocol for for a public blockchain!
  22. Casper the Friendly GHOST (TFG) The fundamental difference between this

    protocol and Casper FFG is that, here, blocks themselves become votes. Validators no longer need to vote on the best chain, they just “run the fork choice” and then make a new block when they are supposed to. The major missing piece of the specification for Casper TFG is validator strategies and incentives.
  23. CBC Casper In summary: it’s more general, less well specified,

    and farther out. It’s also what I work on, as well as incredibly interesting research! Reach out (come chat after) if you’re interested in getting involved.
  24. Solutions from PoS - Energy usage - Miners/validators don’t need

    to use as much electricity! - Expensive - We can pay them a lot less (see above: they do less work) - Large economies of scale - When staking, a dollar is a dollar - Incentives for cartels to form - 51% attacks have a cost, censorship decreases profits
  25. Nothing at Stake! Security deposits and slashing effectively solve this

    problem. Validators cannot “51% attack” without violating slashing conditions, and thus their entire deposit can be slashed. It’s as if 51% attacking causing your mining farm to burn down. Check out the proof: https://tinyurl.com/current-casper
  26. Rich get richer This is totally true in PoW (the

    rich have the ability to buy mining equipment). PoS, however, has less centralization pressure due to - No massive economies of scale - Less incentive to form cartels. Also, we are paying much less!
  27. PoS is a perpetual motion machine! It having security would

    violate the laws of physics. PoS security is based not just on lower rewards, but the fact that validators are putting economic value-at-loss. Aka, we can pay much less in the case of rewards, because an attacking validator has to pay some huge amount to attack. PoS security comes from the cost of attacking (which, btw, doesn’t exist for successful attacks in PoW).
  28. Gives coin holders control over the blockchain! At the very

    least, not any more control than it gives miners over the blockchain. Proof of Stake is not a governance mechanism (though some PoS protocols [Cosmos, Polkadot, etc] are adding this).
  29. Stake grinding 1. Blockhash of block n selects creator of

    block n + 1. 2. Note: the creator of block n can manipulate blockhash of n, giving themself an unfair advantage in being selected for block n + 1! Solutions: - Secret sharing, deterministic threshold signatures (Dfinity), RANDAO; not a fundamental problem like NaS.
  30. To attack PoS, all you have to do is fork

    away the rules that get you slashed! This isn’t any different than randomly changing Bitcoin’s PoW’s hashing algorithm while 51% attacking. Aka, no one will follow you by default, so there isn’t much risk of this being a viable attack.
  31. MC = MR! Thus, nothing is cheaper than PoW! As

    we can pay significantly lower rewards to validators for the same level of security (or cost of attack), MR is lower, so MC is as well.
  32. Impossible to resolve a network split like PoW! We can

    choose consistency or availability. Tendermint chooses consistency, and stops making blocks in the case of a network split. Casper(s) choose availability, and resolves the network split when the network rejoins (we still have a forkchoice!). However, note that this is strictly better than PoW, b/c both sides can see that this is happening!
  33. PoS isn’t finished! There are still many open problems and

    questions. For example: - What are parameterizations of the incentives is best? - How do we best deal with faults that we can’t blame on a specific validator? - How does all of this relate to sharding, etc? - How can we guarantee the implementation of this is correct? - etc.
  34. Links! PoS FAQ: tinyurl.com/pos-questions Casper 101: tinyurl.com/pos-casper-101 Current Casper Spec/Safety

    Prf: tinyurl.com/current-casper Correct-by-construction Casper: tinyurl.com/intro-to-cbc
  35. If any of this sounds interesting to you, and you

    want to start contributing, reach out (and come chat :D)! [email protected]