Hacker News new | ask | show | jobs
by vbuterin 1970 days ago
There's a couple things wrong here:

> Proof of Stake not only replicates the same dynamics that Bitcoin was designed to eliminate (more wealth -> more power in system)

There is no legitimate sense in which PoS _is_ an instance of "rich have more power and get richer" but PoW is not. In fact, PoW is _worse_ than PoS in this regard, because PoW has economies of scale (if someone with a $100k investment earns $10k/year, someone with a $100m investment can earn significantly more than $10m/year). PoS on the other hand is much closer to a clean "what you earn is proportional to what you put in" design, which is realistically the best that you can do in an anonymous system where users can generate as many independent identities as they want.

> can only be made secure against a maximum of ⅓ byzantine actors, compared to Proof of Work's superior ½.

This is also not true. The 1/3 bound is for safety-under-asynchrony (a form of safety for which PoW's security margin is zero). If you assume synchrony, then PoS protocols' safety approaches 50% much like PoW does. Protocols like Casper FFG combine the "best of both worlds", giving you both of those security guarantees (50% BFT if the network is good, 33% BFT if the network is terrible) at the same time.

3 comments

> There is no legitimate sense in which PoS _is_ an instance of "rich have more power and get richer" but PoW is not.

In PoW, miners must sell their tokens to buy capital-intensive mining equipment and power to stay competitive. In PoS, stakers have no incentive to sell enough tokens to anyone who could turn around and stake them as a competitor, since that would cut into the seller's future staking rewards.

> The 1/3 bound is for safety-under-asynchrony (a form of safety for which PoW's security margin is zero). If you assume synchrony, then PoS protocols' safety approaches 50% much like PoW does.

First, consensus protocols can be trivially safe regardless of the network's behavior -- you simply require a majority vote for any proposed agreement. Second, any consensus protocol can only remain live as long as there are no more than f faults out of 3f+1 replicas. This is again irrespective of the network model -- Leslie Lamport's proofs do not make any assumptions about the network.

> Second, any consensus protocol can only remain live as long as there are no more than f faults out of 3f+1 replicas. This is again irrespective of the network model

We actually know of consensus protocols that require synchrony including between participants and clients that go up to 99% fault tolerance for both liveness and safety; in fact Lamport himself described one in his original paper (remember that it's "written messages" and not "oral messages" in his vocab that's the relevant category; these days public key cryptography is cheap and uncontroversial so there's no need to care about the "oral" case). There's also a table on page 291 in the 1988 DLS paper (see https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf, the "authenticated byzantine" row and the "synchronous" column) that gives an overview of the fault tolerance levels in various different cases.

The original definition of consensus did not have a notion of passive clients needing to learn the result, so the "active participants synchronous, passive clients asynchronous" model common in blockchain land was not really analyzed well back then. It turns out that with a synchronous network, the passive client requirement is what brings safety and liveness down from 99% to 50%. And it also happens that the 50% fault tolerance protocols are less fragile in the case that the synchrony assumption breaks temporarily.

> We actually know of consensus protocols that require synchrony including between participants and clients that go up to 99% fault tolerance for both liveness and safety; in fact Lamport himself described one in his original paper (remember that it's "written messages" and not "oral messages" in his vocab that's the relevant category; these days public key cryptography is cheap and uncontroversial so there's no need to care about the "oral" case)

The "written messages" protocol does not tell the whole story. If you go back and re-read Lamport '82 [1], the assumptions that make the SM(m) algorithm ("written messages") work at all also make it a practically useless result. In particular, assumption A4(b) (top of page 391) requires that anyone can authenticate any general's messages at all times. How the generals are supposed to learn each other's public keys _without_ an instance of SM(m) is not addressed, but presumably they would need to fall back to OM(m) ("oral messages") to do so. So if you take a BFT system as a whole, where you can't assume the existence of a magical fool-proof way for generals to learn each other's keys a priori, my original claim stands.

> The original definition of consensus did not have a notion of passive clients needing to learn the result, so the "active participants synchronous, passive clients asynchronous" model common in blockchain land was not really analyzed well back then.

Prior literature doesn't consider "passive clients" because they're not protocol participants in the first place. Clients do not participate in deciding agreement; otherwise they wouldn't be called clients.

Last I checked this is very much still the case in blockchain-land. Your wallet (client) does not do anything to help miners/stakers determine the best chain tip or the next block, for example.

So, I'm not sure what you're trying to say here?

> It turns out that with a synchronous network, the passive client requirement is what brings safety and liveness down from 99% to 50%. And it also happens that the 50% fault tolerance protocols are less fragile in the case that the synchrony assumption breaks temporarily.

Unless you're assuming the existence of the magic fool-proof public-key distribution mechanism required for SM(m) to work, you're not going to get liveness unless you're either (a) assuming nodes do not exhibit arbitrary failure modes, or (b) requiring at least 2/3+e nodes are honest.

[1] https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf

EDIT: wrong date for Lamport

Oooh. Its the man himself!

Curious about what you think about ourboros/cardano! Pros cons vs eth?

When I last looked at Ouroboros it still had the property that there's only "one confirmation per slot", so you need to wait ~log(n) slots before an attacker has a <1/n probability of reversing the chain. I personally think that a good PoS system should strive to have hundreds of confirmations per slot the way eth2's LMD GHOST does. That said, it's very possible that there's an improved version of Ouroboros that already does this and I just haven't caught up to it yet.
Is it realistic, assuming a heterogenous network the Internet, for having high percentage of block dissemination and 100 confirmations in almost every node in 12 seconds (and how many peer connections are assumed per node?) Would not that segment the network? Sorry, I am just asking as I have no knowledge how ETH 2.0 and its LMD GHOST works.
Hey Vitalik, looking to really get into the weeds of blockchain like you. There seems to be a barrier between new folks and engaging fully in learning material. Just too much of a learning curve, got my hands on everything I could find but am now stuck, where do you suggest I find the most information on especially the math behind it all?
FYI - this is the founder of Ethereum
Sorry, but for me, there are no idols and gods exist, but simply fallible humans, with no exception.