Indeed they don't, but even running two database servers (let alone more for e.g. geographic redundancy) is already more resource intensive than running a full node for a proof-of-stake blockchain. You might as well just run that node and get that resiliency basically for free.
Not every usecase requires that sort of resiliency, of course, nor does every use case prioritize it above latency and throughput; nobody except the truly deranged are asserting that a blockchain could or should replace every SQL database out there. For those who do need that sort of resiliency, though, a public blockchain is much more cost-effective.
> running a full node for a proof-of-stake blockchain
Are there any extant proof-of-stake blockchains that achieve the security guarantees necessary to make a currency viable? Last I heard proof-of-stake was still a hypothetical idea, not something that someone had actually managed to make a working currency with, and that all of the cryptocurrencies in common use were still using proof-of-work (which is of course much more resource intensive).
Proof-of-stake is possible, but requires an honest majority of stakers continuously online.
If you want to eliminate Sybil attacks in PoS, there is no way of externally validating which branch of a split chain is legitimate. Each of them has a majority of stake backing it.
As for PoW however, you can just look at the total work proven.
> Proof-of-stake is possible, but requires an honest majority of stakers continuously online.
Which is itself possible by penalizing stake pools that go offline, thus motivating them to maximize uptime. That's how Ouroboros-based chains (Cardano, Polkadot) do it (among other mitigations against various attacks).
> If you want to eliminate Sybil attacks in PoS, there is no way of externally validating which branch of a split chain is legitimate. Each of them has a majority of stake backing it.
Which is why Ouroboros-based chains consider the "pledged stake" (put simply: an upfront collateral) of each pool when selecting one to control the next block and receive the corresponding rewards. This has its own implications (in particular, the pledge needs to be high enough to deter would-be Sybil attackers but not so high that it's unattainable to honest pool operators), but it seems to be effective in practice.
>Which is itself possible by penalizing stake pools that go offline, thus motivating them to maximize uptime.
This is still unfair to stakers that legitimately have infra disruptions. I have not seen any design for PoS that is actually fair and reasonable and I doubt it will ever happen because this is simply not something you want to just put in an algorithm. The problem space fundamentally requires human intervention at a high level.
> This is still unfair to stakers that legitimately have infra disruptions.
I'd hardly characterize that as "unfair"; it's no more unfair than any other perceived correlation between uptime and trustworthiness.
> The problem space fundamentally requires human intervention at a high level.
It fundamentally requires the opposite. The more human intervention possible, the more room for exploitation and corruption and unfairness. This is evident both within the crypto space (Safemoon comes to mind) and outside of it (the legacy financial system comes to mind).
>it's no more unfair than any other perceived correlation between uptime and trustworthiness.
I am saying that correlation inherently makes no sense. Uptime isn't the same as trustworthiness, that assumption is only made because designers of blockchain algorithms have bizarrely decided that "trustworthiness" is not a real thing so they need to continuously look for other things to use as a substitute for it, instead of just using what most people (including many promoters of cryptocurrencies in their real, physical lives) use: trustworthiness.
>It fundamentally requires the opposite.
No, this is extremely, extremely, extremely wrong on every possible level. Even from the perspective of a cryptocurrency, this is extremely wrong. I can't stress this enough. You are creating a system for humans to use for human purposes. The entire point of it is human intervention. When designing these blockchain algorithms (which I should remind you are designed and maintained by humans as code that needs to be continuously maintained by humans) all that happens is you encode that particular form of exploitation and corruption and unfairness into the system itself. Even within your example it's wrong; discriminating against those with bad uptime enables exploitation and corruption towards areas that have bad infra. And remember since this is code that can be updated and changed by humans it will be vulnerable to the same level of corruption that you see anywhere else. You might trust the maintainers not to do this but now you're back to the same old trustworthiness again.
The former is pretty darn important for the latter. How can I trust something that is prone to outages?
> You are creating a system for humans to use for human purposes. The entire point of it is human intervention.
One does not follow from the other.
> When designing these blockchain algorithms (which I should remind you are designed and maintained by humans as code that needs to be continuously maintained by humans) all that happens is you encode that particular form of exploitation and corruption and unfairness into the system itself.
Well then it's a good thing that code is available to the general public and can be audited by the general public.
> Even within your example it's wrong; discriminating against those with bad uptime enables exploitation and corruption towards areas that have bad infra.
The correct response would be to improve infra in those areas, or for people in those areas to use one of the umpteen gajillion VPS providers in the world to run their stake pools instead of trying to do so from their closets.
> And remember since this is code that can be updated and changed by humans it will be vulnerable to the same level of corruption that you see anywhere else. You might trust the maintainers not to do this but now you're back to the same old trustworthiness again.
Then it's a good thing that the code in question is open to audit by the general public and that new versions of the code require consent from the network before they actually go "live" in any meaningful sense.
Not every usecase requires that sort of resiliency, of course, nor does every use case prioritize it above latency and throughput; nobody except the truly deranged are asserting that a blockchain could or should replace every SQL database out there. For those who do need that sort of resiliency, though, a public blockchain is much more cost-effective.