Proof of Steak is obviously better: https://meatver.se
Also https://steak.network/
"Decentralized networks are a rare medium well-done."
Proof of stake is incapable of producing a consensus
811–820 of 822 posts
Re: Proof of stake is incapable of producing a consensus
#812Earlier quoted context omitted.
The issue is what constitutes a sufficient amount of "decentralization". Extremists who may or may not have ulterior motives seem to oppose any change which by their estimation might decrease the decentralization. They want to minimize the cost of running a full node without consideration for the fact that optimizing that to the extreme causes transaction fees to go parabolic and thus also prices less well off users…
I see you haven't discovered the wonders of ZKRollups yet. Have a read of the works of Polynya [0]. Ethereum will be a settlement layer for these execution chains that can do thousands of TPS at a fraction of the current fee, and their only limit on TPS is data storage, which will be expanded with data shards. [0] https://polynya.medium.com/
Yeah, I'm aware of that stuff I don't think it will get traction and adds complexity w/o really solving the fundamental problem. My bet is a practical competitor will find a way to balance the different tradeoffs and the winner will be a so called L1 network.
Re: Proof of stake is incapable of producing a consensus
#813Earlier quoted context omitted.
I'm not sure what you are linking to. This looks like a tweet from 2016.
I think what the parent referring to is the DAO hack (from 2016) and how Ethereum’s response was to renege on “Code is Law” (and the integrity of the blockchain) in order to void those transactions (smartcontract exploits), which is a case of centralization resurfacing because VB could subvert the proof of work system when his own money was at risk. Ethereum Classic is the fork that refused to rewrite the blockchain…
I've recently read that the blockchain was not rewritten or unrolled. It was actually executed forward through an "irregular state change". In other words, it made a new transaction instead of erasing or modifying old transactions, and that was done with consensus of all those who ran the ETH client. Those who didn't agree went to ETC, but the market chose ETH in the end.
Re: Proof of stake is incapable of producing a consensus
#814Earlier quoted context omitted.
I think what the parent referring to is the DAO hack (from 2016) and how Ethereum’s response was to renege on “Code is Law” (and the integrity of the blockchain) in order to void those transactions (smartcontract exploits), which is a case of centralization resurfacing because VB could subvert the proof of work system when his own money was at risk. Ethereum Classic is the fork that refused to rewrite the blockchain…
I've recently read that the blockchain was not rewritten or unrolled. It was actually executed forward through an "irregular state change". In other words, it made a new transaction instead of erasing or modifying old transactions, and that was done with consensus of all those who ran the ETH client. Those who didn't agree went to ETC, but the market chose ETH in the end.
Regardless of how you word it, it amounts to the same thing: the protocol and signed, validated history say this happened, now we act like they did not, which is a violation of blockchain integrity.
Re: Proof of stake is incapable of producing a consensus
#815Earlier quoted context omitted.
You could have brought up hard left subreddits getting banned too. Like Chapo. So it doesn’t seem like only the right is persecuted/appearing to continue the trope of how the right are such victims.
Same thing
How is it the same thing? Hard left doesn’t victimize themselves while calling others snowflakes all the time like /r/Donald people or sympathizers.
Re: Proof of stake is incapable of producing a consensus
#816Earlier quoted context omitted.
The site isn’t particularly accessible for a quick discussion so I appreciate your explanation, thank you. However, I’m not sure I understand how this is supposed to help. Proving that a few seconds passed just slows down block generation a little, but this cannot be a significant barrier to block generation or else you just have a full PoW system again. And if it’s not a significant barrier then it’s not clear to me…
With VDF you cannot rebuild the 100 minutes worth of blocks in less than 100 minutes, because with the VDF logging, you just proved that you would need at least 100 minutes to go from block n to n+(100 minutes). You can check in 10 seconds, but can only produce in 100 minutes, just like you can check in an instant that a bitcoin block starts with enough zeroes. So it defines the rate of generating blocks. Of course,…
Ok I just looked at https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3b... for an explanation. VDF is proof of work. It's just proof of sequential work. It does seem plausible that a VDF would significantly reduce the amount of computing hardware being used in generating blocks, but it fundamentally is still a proof-of-work scheme, just one that requires faster processors rather than more nodes if you want to speed it up.
The thing though is that this doesn't prove that X seconds have passed. It proves that X seconds have passed on whatever baseline hardware has been used to calibrate it. I don't know who actually computes the VDF in the proposed proof-of-stake schemes, though I would assume it's "whoever is proposing a block" (is this the same as the staker? Does this mean every single staker is picking a block and computing their own VDF, meaning everyone is still burning CPU?). And this means the VDF can only establish a minimum CPU requirement. It can say "X seconds have passed on the minimum hardware we're requiring at the moment", but anyone with faster hardware can still compute it faster.
And also because this PoW scheme cannot require more than X seconds for any participant to compute, it means an attacker that starts computing their alternative blockchain at the same time as the block they want to replace faces no difficulty. All this does is interferes with the ability to decide after the fact that you want to attempt to replace history. And even then, if you have hardware faster than the baseline, you can still reach back in time to recalculate a block, you just have to wait longer to do so. And by that I mean if you want to edit a block from 100 minutes ago, and you've got a CPU that's twice as fast as whatever the VDF is tuned for, then it just takes you 100 minutes to compute the replacement blockchain (50 minutes to compute the past 100 minutes, and 50 minutes to compute the new blocks that have been added since you started the attack). So after 100 minutes you now have an alternative chain that everyone thinks took 200 minutes to compute.
Which means now we're just back at the problem of "attacking consensus", where nobody can look at the two blockchains and see within the system which one was calculated first.
---
I suppose the VDF could be calculated by some volunteer with the fastest hardware, though this requires rewarding them for doing so (which means you basically have a monopolist sucking up all of the VDF rewards and no real incentive for nearly all participants to even try and compete). And this is still attackable by someone who can put together hardware that is even just slightly faster than then volunteer. It just takes longer. If the security of the system relies on a volunteer being assumed to have the fastest hardware on the planet, then the system isn't secure. I also question what happens in this scenario when the volunteer goes offline and nobody else has hardware that's as fast. Now the next block isn't ready in X seconds. I assume there's some protocol for "oops nobody has finished computing the VDF in time", but this does provide another avenue of attack for anyone in a position to disrupt the volunteer's connection to the network. Of course, anyone in a position to do that is likely to have access to unusually fast hardware already, but the point is that you cannot rely on the idea that "nobody can possibly calculate this block faster than the VDF is tuned for".
This attack is possible in Bitcoin too, except because Bitcoin is parallelizable, the defense there is that this attack requires spending more money than it is worth as the computing power used to calculate blocks is roughly a function of the value of the network. The danger there is generally in centralizing too much of the computing power among too few participants rather than an outsider breaking the scheme. This attack does work on smaller PoW coins of course, generally by folks who control a chunk of Bitcoin computing power and just redirect it temporarily (if the value in attacking the coin is greater than the expected bitcoin mining rewards for the time it takes to do the attack, then this makes sense).
Honestly, it really seems like we should only have one global PoW network, and everything else should use other systems. Perhaps they should satisfy security by doing things like VDFs for short-term security and storing their blockchain hashes into Bitcoin for long-term security. Bitcoin using up a ton of power is still a problem of course, but maybe there's some sort of approach that can be used to solve the problem of "PoW to establish a global distributed clock" once you remove the "and we want to use this as a currency" part that doesn't invoke a massive arms race. This may involve ditching the idea of "anyone can participate", which also then allows you to change the incentives for running the PoW scheme.
---
Edit: I suppose the VDF's input might not be "the block being computed" but instead "the previous block", and the output then used to elect participants who are then trusted to build the new block. This would allow the new block to indicate whether the VDF actually took longer than expected. But then we're back at a probabilistic function with PoS, where those with the highest stake are now most likely to be trusted and therefore are in a position to abuse that trust.
I suppose reading up more on PoS systems might answer this question. But I really don't want to do that. I've already spent far longer on this than I intended to.
Re: Proof of stake is incapable of producing a consensus
#817Earlier quoted context omitted.
With VDF you cannot rebuild the 100 minutes worth of blocks in less than 100 minutes, because with the VDF logging, you just proved that you would need at least 100 minutes to go from block n to n+(100 minutes). You can check in 10 seconds, but can only produce in 100 minutes, just like you can check in an instant that a bitcoin block starts with enough zeroes. So it defines the rate of generating blocks. Of course,…
Ok I just looked at https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3b... for an explanation. VDF is proof of work. It's just proof of sequential work. It does seem plausible that a VDF would significantly reduce the amount of computing hardware being used in generating blocks, but it fundamentally is still a proof-of-work scheme, just one that requires faster processors rather than more nodes if you want t…
I think you basically ask the right questions. But when you have progressed in your understanding, and you're confronted with the next problem caused by PoS, you seem to assume that PoS is flawed, because you can't immediately think of a solution (which is expected, that's quite a hard problem). The reality is that the issues you mention are well identified and they have solutions for them.
About VDFs, there is a tolerance, you need to be in the same ballpark as the fastest, not _the_ absolute fastest. The more tolerance you need, the less snappy the PoS blockchain will be. They plan to make a low-power asic for that task, to be as close as the theoretical max speed for that, and have the lowest tolerance margin as a result.
Also, there is a way to reduce all VDFs results so that only one of the whole set of VFS-ers need to be honest.
So it's not one volunteer, but a pool of volunteers, using low powered asics so close to the theoretical max (ie speed of transistor switching) that you couldn't outrun them enough to profit from that speed up. I am not sure if they are incentivized, because it's not costing a lot, but maybe.
> Edit: I suppose the VDF's input might not be "the block being computed" but instead "the previous block", and the output then used to elect participants who are then trusted to build the new block. This would allow the new block to indicate whether the VDF actually took longer than expected.
Indeed, that's what I thought I was saying, but maybe I was not clear enough.
Re: Proof of stake is incapable of producing a consensus
#818Earlier quoted context omitted.
In a chain like Tezos, the validator software is relatively easy to run if you have a Raspberry Pi and some terminal chops, and a lot of hobbyists do stake this way. But it’s easier for most people to delegate to another party. This is where decentralized staking pools for ETH2[1] built around smart contract interactions could be a good alternative for many users, and may compete with centralized staking platforms. T…
> The mere fact that these peer-to-peer and decentralized alternatives exist, and that some portion of users will prefer to use them, is what makes this technology distinct. I can imagine projects that can run on cheap hardware thriving but what happens when you put the weight of exchanges like Coinbase and their users against the hobbyst node count?
This is already happening; centralized exchanges and staking pools like Kraken make up a high percentage of ETH2 validators (just as PoW seems to gravitate toward large mining pools).
Despite that, PoS has the benefit of offering decentralized staking pools like RocketPool, and the fact that they are growing may indicate that the chain will over time become more decentralized and less able to be centrally attacked[1]. The PoS mechanism itself is also perhaps more resilient to these kind of attacks, see [2].
None of this mechanism is as simple as PoW (which has worked quite well for BTC and ETH so far), but the environmental cost makes it worth exploring an alternative mechanism.
[1] - https://uk.style.yahoo.com/valid-points-ethereum-2-0-1130005...
Re: Proof of stake is incapable of producing a consensus
#819Re: Proof of stake is incapable of producing a consensus
#820Earlier quoted context omitted.
I've recently read that the blockchain was not rewritten or unrolled. It was actually executed forward through an "irregular state change". In other words, it made a new transaction instead of erasing or modifying old transactions, and that was done with consensus of all those who ran the ETH client. Those who didn't agree went to ETC, but the market chose ETH in the end.
Regardless of how you word it, it amounts to the same thing: the protocol and signed, validated history say this happened, now we act like they did not, which is a violation of blockchain integrity.
No, that's not what happened. No history was changed, and nothing was re-validated as you suggest. There was no "violation of blockchain integrity". The only thing that happened was that the upgraded version executed what's known as an "irregular state-change" which moved the ETH from TheDAO's smart contract to a new secure contract. So, it wasn't a roll-back, but a roll-forward, and the change was mined using PoW in accordance with all the blockchain block selection rules.