Hacker News new | ask | show | jobs
by 676234e117 1416 days ago
What you are describing is a protocol-level bug, rather than smart contract bug. The merge has already occurred successfully a number of times on test networks, so it seems unlikely at this point. But if a catastrophic failure were to occur on mainnet, clients would just revert or fork to a working state.

The reason you cannot just roll back a smart contract exploit like Nomad's is that it is very hard to build consensus across the entire protocol unless it is something that affects many users. The only time this happened was with the DAO which held something like 15% of all Ethers at the time, and so it affected the entire network. Compare this to Nomad which held something like 0.1% of Eth's total circulating supply.

1 comments

> if a catastrophic failure were to occur on mainnet, clients would just revert or fork to a working state.

Except with PoS, it is different. People keep applying the PoW mentality of a fork to PoS and it just doesn't work that way. Jeff wrote a good blog post [1] on this a while back that took me a long time to come to terms with. It boils down to this paragraph:

  Proof-of-stake is inherently self-referential. It is possible to have two perfectly consistent, equally valid chains - perhaps with different stakers. Since “stake” is defined within a blockchain, it cannot be used to pick between two blockchains. Under the right kind of stress, the real, unwritten meta-consensus protocol that determines "which blockchain do we pay attention to?" will be revealed. Exactly what that is will depend on the nature of the fork.

This is untested on ETH PoS and could result in a significant loss in value for ETH holders. Not only that, but it gets even more complicated with stablecoins that are on ETH. What makes all of this quite interesting is the exchanges who get to decide which USDC on ETH they sell to you. Likely a big reason why exchanges, like Coinbase, are some of the largest ETH stakers.

[1] https://github.com/stickfigure/blog/wiki/Proof-Of-Stake-Wear...

The article is not really presenting any strong arguments aside from literal hand waving the "<complexity>". The same hand waves could be made for PoW. See the last time it made discussion[1].

The article suggests that two chains can simultaneously exist but that would invalidate the protocol, which will always choose one using LMD GHOST. You can read more about it here[2].

[1] https://news.ycombinator.com/item?id=27235668

[2] https://eth2book.info/altair/part2/consensus

> The same hand waves could be made for PoW.

Not really. PoW is orders of magnitude simpler than PoS and is vastly easier to reason about. I can explain the concepts around PoW in 5 minutes to someone who doesn't understand it. PoS is a lot closer to a rube goldberg contraption than PoW is. The proof in all of this is the years it has taken to even get to the point we are at today.

> Articles describing the complexity involved

The whole point of my original comment is that this is A LOT more complex than a bridge contract and therefore will be subject to a larger attack surface. Thanks for validating that point.

I agree with your point that PoS is more complex and has a wider attack net than PoW, but I don’t agree that users will not be able to coordinate on a new fork in case of a protocol failure. The worst that may happen is that another hard fork emerges, where the majority of the ecosystem follows a single chain with the bug reverted, and some group of outliers such as disgruntled BTC miners or people who profited immensely from the bug decide to try their luck with a smaller fork. And that is fine... users are free to decide what fork to follow, and they can run client software that chooses a different chain.
> The worst that may happen is that another hard fork emerges,

Yes, but what will dictate that? ETH today is the hard fork (from what is now ETC).

How much loss will it take to decide what to do?

Where is the failure plan?

By “loss” do you mean that of the exploiters losing tokens because the community decided not to follow the hacked chain?

The goal of all the shadow forks and merge testnets is to find the different edge cases and failure states to answer those questions of “what is the failure plan?” If mainnet merge somehow does not succeed despite these tests and all clients fail to produce blocks, the merge can just be delayed until the bugs are resolved. If mainnet merge succeeds but later a bug emerges, users can coordinate a change to revert the lost funds.

The second link is mostly a high-level overview, and then lots of empty subsections (TODOs).
If you want more details you can always read the Gasper paper[1], the spec[2], or client code.

It is complex to somebody not familiar with consensus and blockchain execution, but you might say that about any modern engineering. PoW is undoubtedly simpler but also exponentially more environmentally destructive.

[1] https://arxiv.org/abs/2003.03052

[2] https://github.com/ethereum/consensus-specs/blob/dev/specs/p...

I personally find the ESG argument to be a misnomer. You're trading security and a well defined execution layer, for a significant amount of complexity. If you want to moralize energy use, then you have to apply it at all levels, not just call PoW bad for the environment.