[676234e117]

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

[latchkey]

> 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.

[676234e117]

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.

[latchkey]

> 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?

[676234e117]

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.

[latchkey]

Loss could come in many forms. We can't predict that future yet, but we can be wary of it.

> the merge can just be delayed until the bugs are resolved

This is one of the losses. Every time the merge is delayed, price drops. Price is currently trending higher right now because the merge looks like it is on track.

Delaying the merge also has a loss... for the miners who are currently securing the network. aka: the bomb. The bomb is an embarrassment because every time it gets pushed out, that is essentially the minimum amount of time before the merge can happen.

> users can coordinate a change to revert the lost funds.

How. I want a detailed plan. So far, I haven't seen it.

[676234e117]

> Every time the merge is delayed, price drops

You are conflating "people losing tokens" with "people losing the USD value of their tokens." It is very likely that the market becomes unpredictable before and after the merge, value of ETH may plummet or skyrocket, and holders of ETH should be prepared for that.

> The bomb is an embarrassment because every time it gets pushed out, that is essentially the minimum amount of time before the merge can happen.

That is not how the bomb works. It is a soft deadline. If the developers feel the merge is ready, they can initiate it before the bomb occurs, and miners will immediately be forced to transition their hardware to other PoW networks. If the developers do not feel the merge is ready, and the bomb is fast approaching, they can delay the bomb by another month or even a year and it will not have an impact on the timing of when they actually decide to initiate the merge.

If the worst that can happen is "embarrassment" for having to delay the merge again to fix a critical bug, I think you are overblowing this. The developers will happily delay the merge until all the bugs are fixed, and the users are happy to have this happen as they would rather wait for a working merge than rush toward a broken one.

> How. I want a detailed plan. So far, I haven't seen it.

Every time the protocol rules change, developers are activating a fork by coming to consensus on the new rules - all client software must coordinate code updates to match the new rules. Eth core developers and client teams have been doing this regularly over the years, and especially during the approach to the merge. They can coordinate a revert or fork, just as they have coordinated the past several forks[1], to fix these issues.

It is fine to imagine a hypothetical failure case for the merge but this does not mean "it cannot be fixed." It might be messy, the value may drop, coordinating the fix may take some hours or days, and it is even possible the chain stops producing blocks for some short while if it is very catastrophic. Users still holding ETH going into the merge should be prepared for these situations, it is probably the most significant development in crypto currency and DLT since the Bitcoin genesis block.

[1] https://ethereum.org/en/history/

[FabHK]

The second link is mostly a high-level overview, and then lots of empty subsections (TODOs).

[676234e117]

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...

[latchkey]

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.