I don't get your comment: Ethereum itself has worked without any issue since it came out, in 2015 (?) or so. Many smart contracts, not built by the core Ethereum devs, have been exploited, but from Ethereum's point of view everything worked flawlessly.
Why would the Ethereum devs, which have create a blockchain working perfectly fine since seven years (including many upgrades), suddenly screw up the merge to PoS badly?
I mean: I don't doubt we'll see many more hacks (and I don't know why so many people are so keen on putting so much money in smart contracts) but the people in charge of Ethereum itself seems to be quite competent and have a track records of several years without any exploit to prove it.
Switching to an entirely new consensus model, that has never been done before, is complicated and a big reason why it has taken as long as it has.
Furthermore, there is a giant target (huge sum of money) on ETH's back now. If you had an exploit for PoS, why would you reveal it early?
As the person below also states... they could just fork and fix things, but this time, it will be a lot harder to do so without entirely destroying the value of ETH.
This is a massively risky venture that takes more than just hope and prayers. As we've seen in many many hacks over the last few years, even the most competent developers can miss something crucial.
Nope. The ETH is just in a rather simple write only deposit contract on ETH1. [1] It is also not 'all' ETH, since there is no hard cap on the total amount of ETH in existence.
It is also a bit more complicated than just looking at the beacon chain. That beacon chain has zero value tied to it. So while it has been running just fine, there hasn't been a reason to attack it. It also hasn't been used to actually do anything really... and now there is a use. There is also a lot more communication going on between nodes that didn't exist before. All of these things become attack surfaces.
[1] https://etherscan.io/address/0x00000000219ab540356cbb839cbe0...
- 10% of the current supply of ETH is in the deposit contract, and can't be withdrawn from the deposit contract.
- Every address that deposited ETH into that contract got a corresponding balance of "ETH" on the beacon chain. (I'll call it "ETH" instead of just ETH to avoid arguing over whether it's really ETH.)
- The beacon chain is functioning as designed, and the "ETH" balances of various addresses are getting changed over time. The economic incentives appear to be working. People are keeping their nodes up and running to get rewards, and trying to avoid getting slashed.
- The plan is for stakers to be able to withdraw their balances to the main chain, from the beacon chain. When someone withdraws, an ETH balance will be incremented on the main chain, and the same address will get its "ETH" decremented on the beacon chain.
Right now, the contract is one way and there is no way to withdraw. The code hasn't been developed yet. The ETH or "ETH" or whatever, are secure because there literally cannot be insecurity without some code to break.
Heck, even "The Merge" doesn't enable withdraw... it is scheduled for some time after (still to be decided and coded... more potential security issues) and is of course a slow trickle too (first people who can withdraw win the short market). That 10% is about as secure as you can possibly be in that it is effectively burned at this point and will require yet another hard fork to unburn it.
Let's go back to the premise of my original comment:
PoS is a lot more complicated than PoW and offers a much wider attack surface.
Any large mistake in the code that causes financial loss is going to go down a huge rabbit hole of how to manage consensus around fork choices and will likely have at least a short term devastating effect on the market.
I want to see PoS succeed, but as a 20+ year developer, I'm very skeptical it will go off without a hitch.
As for rollback... that's what created ETC, but this time, it is different... with PoS, the 'stake' is tied up in the network. It isn't external, like it is with PoW and isn't as easy to just fork. You're effectively now forced to convince everyone to follow another canonical chain, but you don't have an external way to do so. Forking becomes a lot harder. It also becomes a lot more complicated and hasn't even been done before... how much 'testing' has that gotten?
This gets messy fast when there is an issue and even worse is that there isn't a published plan for how to deal with things when they do come up. Everyone is betting on it all executing perfectly and given the complexity and value at stake here, chances are that at some point now, or in the future, it won't go well.
[1] https://github.com/stickfigure/blog/wiki/Proof-Of-Stake-Wear...
https://en.wikipedia.org/wiki/The_DAO_(organization) https://en.wikipedia.org/wiki/Ethereum#Launch_and_the_DAO_ev... https://en.wikipedia.org/wiki/Ethereum_Classic
Before 2018, Ethereum has a similar downtime to Solana
Ethereum is continuously developed to remove bugs.
For example: Until 2017, it was possible to sent a specifically signed transaction (without the correct private key) that resulted in the msg.sender having null sender address. This was fixed in EIP-86
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.
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 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].
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.
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?
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 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.
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.
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...