Web3.0’s value proposition-to embrace paradigm shift from consumption to ownership
Introduction Reviewing the history of internet development in the past few decades, it can be summarized as three different stages: Web 1.0, Web 2.0 and Web 3.0. Web 1.0 is generally considered to have begun in early 1990s offering basic read-only webpages without any user interaction. Web 2.0 came roughly at the beginning of 21st century and continued to today, where users not only read but also create the content based on various social media platforms namely YouTube, Twitter and Meta（Faceb...
Project Brief - THORChain ($RUNE)
Project Description. THORChain (Thor Chain) is a decentralized cross-chain AMM trading protocol that was just created by an anonymous group of cryptocurrency developers at Binance's hackathon in 2018. With THORCHain, users can trade tokens between different L1 blockchains, eliminating the need to trade through a centralized exchange. For users who have always sought privacy protection and asset safekeeping, THORChain offers one of the key features to replace centralized exchanges (CEX): ...
Project Information - Ronin ($RON)
Project ProfileRonin is a sidechain of Ethernet and a dedicated chain of Axie Infinity, the first major chain tour. It aims to solve the problem of congestion and high Gas fee of Ether L1, providing reliable, fast and reasonable cost for the development of the game, and also avoiding the scaling problem that will arise later by using the existing blockchain. Ronin Ecology Ronin Wallet Bridge The Ronin Explorer Purchase Staking Official website: https://bridge.roninchain.com/ Twitter: https://...
Web3.0’s value proposition-to embrace paradigm shift from consumption to ownership
Introduction Reviewing the history of internet development in the past few decades, it can be summarized as three different stages: Web 1.0, Web 2.0 and Web 3.0. Web 1.0 is generally considered to have begun in early 1990s offering basic read-only webpages without any user interaction. Web 2.0 came roughly at the beginning of 21st century and continued to today, where users not only read but also create the content based on various social media platforms namely YouTube, Twitter and Meta（Faceb...
Project Brief - THORChain ($RUNE)
Project Description. THORChain (Thor Chain) is a decentralized cross-chain AMM trading protocol that was just created by an anonymous group of cryptocurrency developers at Binance's hackathon in 2018. With THORCHain, users can trade tokens between different L1 blockchains, eliminating the need to trade through a centralized exchange. For users who have always sought privacy protection and asset safekeeping, THORChain offers one of the key features to replace centralized exchanges (CEX): ...
Project Information - Ronin ($RON)
Project ProfileRonin is a sidechain of Ethernet and a dedicated chain of Axie Infinity, the first major chain tour. It aims to solve the problem of congestion and high Gas fee of Ether L1, providing reliable, fast and reasonable cost for the development of the game, and also avoiding the scaling problem that will arise later by using the existing blockchain. Ronin Ecology Ronin Wallet Bridge The Ronin Explorer Purchase Staking Official website: https://bridge.roninchain.com/ Twitter: https://...
Share Dialog
Share Dialog
Subscribe to coke
Subscribe to coke
<100 subscribers
<100 subscribers
You should definitely read this this week, Tim Beiko brings AllCoreDevs Update 011, a comprehensive article that tells us what's left on the road to the merger of Ether.
So here's the question, when will the merger happen?
This is the only question many people are interested in right now, and the official answer is "when it's ready", which is true, but not very helpful. So, let's break it down.
There are two somewhat separate parts involved, and they make the prediction less straightforward. The first part is simple, i.e., the client's readiness for the merger, while the second part is the difficulty bomb for Ether.
What is Ether's Difficulty Bomb?
The Difficulty Bomb (sometimes referred to as a glacial period) is a mechanism that has existed since the early days of Ether that functions by starting to exponentially increase the difficulty of proof-of-work (PoW) block mining after a certain block height is reached, which in turn increases the time between blocks. There is currently a Dune dashboard showing how block productivity drops rapidly as the difficulty bomb takes effect, which we can then recover from by resetting it with a hard fork.
The idea of the difficulty bomb is twofold, first it provides a mandatory feature for developers to dismantle or delay the difficulty bomb requiring a hard fork, the idea is that if we were to do this via a hard fork then we would use the opportunity to do a protocol upgrade. Especially early on, the purpose of the difficulty bomb was to encourage a rapid shift to a proof-of-stake (PoS) consensus mechanism. In my opinion, it pretty much failed in this regard, as evidenced by (a) the fact that we still haven't successfully moved to PoS and have delayed the difficulty bomb at least 5 times, and (b) the fact that both hard forks, Arrow Glacier and Muir Glacier, only delayed the difficulty bomb and didn't do anything else, and its main impact was simply to complicate the plan.
And the second, more realistic purpose of the difficulty bomb was to prevent miners from continuing to participate in PoW mining after PoS activation. Miners will need to defuse the difficulty bomb themselves, which is not difficult (it only takes one line of code), but the presence of the difficulty bomb effectively forces miners to maintain their own ETH1 client branch after the merge.
In any case, the point is that the current iteration of the difficulty bomb will soon become compelling.
Plan A and Plan B
The ideal path (Plan A), is to perform the merger before the hard bomb becomes a big problem. And the alternate option (Plan B) is to do another delayed bomb-only hard fork to get a few more months to get ready for the merge.
So, it's a race, and Plan A is optimal, but it depends on everything being fully ready before the difficulty bomb destroys Ether. But we don't know exactly when, because time is affected by overall computing power, and we don't know exactly the merge readiness of the client yet.
Most importantly, we hope to have a clearer picture of both by the end of May. By then (or within a few weeks after that), we will have to decide whether to go for it or use a Plan B deferral difficulty bomb like a hard fork. We can't let the decision be made for too long, because organizing a hard fork to defuse the difficulty bomb will also take a few weeks, if needed.
As of now, the test merge seems to be going well (see below), and the latest analysis suggests that the difficulty bomb will not become a serious problem for Ether until mid/late August, when the average block-out time could rise to 20 seconds.
If I were a betting man, I'd bet some USDC on an August merger without delaying the difficulty bomb. But this is by no means financial advice, and don't cry to me if you lose your shirt.
Tim Beiko gives his own take on the merger timeline (which I don't think is substantially different from what is discussed above, for example).
You can join the EF mailing list for updates.
Test Merge
Please see Tim's ACD update for an overview of #TestingTheMerge. You can find notes from the weekly merge testing call here.
Before we get into what developers are doing to test the merge, I want to emphasize the point that if you are running any infrastructure on Ether, you need to be involved in merging to test as well. This is the only real way to make sure your project doesn't break while we're doing this. To that end, my colleague Sajida has put together a merge testing leaderboard to keep track of who's doing the testing.
Mainnet Shadow Forks
Since I last wrote on the topic of merge testing, we have completed 3 mainnet shadow forks, one of which was done in Amsterdam.
Mainnet shadow forks are an excellent test of the merging mechanism and client readiness. They are more or less equivalent to merging the mainnet (although the Ether Foundation and the development team currently control all the validators, which makes shadow forks a little easier). Shadow forks are too cool for me to go into all the details, but in general, as of now, these tests have been a huge success.
The first mainnet shadow fork occurred on April 11, and the following is a summary from Pari.
Marius announced that the shadow fork was a great success, a configuration issue related to gas limitation was found in the Geth client during testing, but the problem was not serious, there were various issues with different clients, but they were found and fixed.
The second mainnet shadow fork occurred during the Devconnect conference on April 23, and the following is a summary from Pari.
This is the first shadow fork where every client survived the merge and managed to stay in sync afterwards, and we're making real progress here!
The third mainnet shadow fork happened on May 5, and this test also passed very well.
More information you can find in the developer conference call transcript.
It includes some new tests on merge synchronization, which found some issues, but they are definitely fixable.
In addition, the Goerli test network has been shadow forked 4 times.
Most importantly, we are planning to merge three existing ethereum testnets in June: Ropsten, Sepolia and Goerli.
Beacon Chain Milestones
As of today, over 10% of ETH is pledged in the Eth2 deposit contract. hildobby.eth assembles a great deposit dashboard that shows the status and history of pledged deposits. The number of active verifiers is now close to 370,000 and growing faster than ever before.
Also, we have some good news in terms of client diversity, Prysm's market share is now less than 50%, which is a much healthier state for the entire beacon chain. In the previous months, Prysm's market share was over 68%, which is a very unstable situation. It seems like it would really help to write some warning articles, but seriously, hats off to the individuals and institutions that have defied the odds and invested time and effort to make changes, because of you Ether is stronger and more secure.
Of course, the battle isn't over yet. The next thing to improve is the diversity of implementation clients, which is even worse than the diversity of previous consensus clients.
Pledges
The pledge page on ethereum.org has been completely revamped and is very nice.
And while Lido has come under some scrutiny recently, Lido is doing exactly the right thing as a tool with a 30%+ share of the pledge market. This seems to have triggered a flurry of transparency. the next chapter of Lido is the updated decentralization roadmap I requested in early March. Beyond that, they share Lido's operator strategy. superphiz has some thoughts on all of this.
Also from Lido, they published an article titled Modeling The Entry Queue Post-Merge, which analyzes how merging might affect Lido's social reward model in the case of very long verifier activation queues.
As for Rocket Pool, Bits Be Trippin gave an overview of Rocket Pool in an interview with Darren Langley, and Rocket Pool announced support for Besu and Nethermind as Eth1 clients in its latest beta release. Yay, client diversity!
Welcome to join #NowhereDAO, a free information and token information sharing platform
You should definitely read this this week, Tim Beiko brings AllCoreDevs Update 011, a comprehensive article that tells us what's left on the road to the merger of Ether.
So here's the question, when will the merger happen?
This is the only question many people are interested in right now, and the official answer is "when it's ready", which is true, but not very helpful. So, let's break it down.
There are two somewhat separate parts involved, and they make the prediction less straightforward. The first part is simple, i.e., the client's readiness for the merger, while the second part is the difficulty bomb for Ether.
What is Ether's Difficulty Bomb?
The Difficulty Bomb (sometimes referred to as a glacial period) is a mechanism that has existed since the early days of Ether that functions by starting to exponentially increase the difficulty of proof-of-work (PoW) block mining after a certain block height is reached, which in turn increases the time between blocks. There is currently a Dune dashboard showing how block productivity drops rapidly as the difficulty bomb takes effect, which we can then recover from by resetting it with a hard fork.
The idea of the difficulty bomb is twofold, first it provides a mandatory feature for developers to dismantle or delay the difficulty bomb requiring a hard fork, the idea is that if we were to do this via a hard fork then we would use the opportunity to do a protocol upgrade. Especially early on, the purpose of the difficulty bomb was to encourage a rapid shift to a proof-of-stake (PoS) consensus mechanism. In my opinion, it pretty much failed in this regard, as evidenced by (a) the fact that we still haven't successfully moved to PoS and have delayed the difficulty bomb at least 5 times, and (b) the fact that both hard forks, Arrow Glacier and Muir Glacier, only delayed the difficulty bomb and didn't do anything else, and its main impact was simply to complicate the plan.
And the second, more realistic purpose of the difficulty bomb was to prevent miners from continuing to participate in PoW mining after PoS activation. Miners will need to defuse the difficulty bomb themselves, which is not difficult (it only takes one line of code), but the presence of the difficulty bomb effectively forces miners to maintain their own ETH1 client branch after the merge.
In any case, the point is that the current iteration of the difficulty bomb will soon become compelling.
Plan A and Plan B
The ideal path (Plan A), is to perform the merger before the hard bomb becomes a big problem. And the alternate option (Plan B) is to do another delayed bomb-only hard fork to get a few more months to get ready for the merge.
So, it's a race, and Plan A is optimal, but it depends on everything being fully ready before the difficulty bomb destroys Ether. But we don't know exactly when, because time is affected by overall computing power, and we don't know exactly the merge readiness of the client yet.
Most importantly, we hope to have a clearer picture of both by the end of May. By then (or within a few weeks after that), we will have to decide whether to go for it or use a Plan B deferral difficulty bomb like a hard fork. We can't let the decision be made for too long, because organizing a hard fork to defuse the difficulty bomb will also take a few weeks, if needed.
As of now, the test merge seems to be going well (see below), and the latest analysis suggests that the difficulty bomb will not become a serious problem for Ether until mid/late August, when the average block-out time could rise to 20 seconds.
If I were a betting man, I'd bet some USDC on an August merger without delaying the difficulty bomb. But this is by no means financial advice, and don't cry to me if you lose your shirt.
Tim Beiko gives his own take on the merger timeline (which I don't think is substantially different from what is discussed above, for example).
You can join the EF mailing list for updates.
Test Merge
Please see Tim's ACD update for an overview of #TestingTheMerge. You can find notes from the weekly merge testing call here.
Before we get into what developers are doing to test the merge, I want to emphasize the point that if you are running any infrastructure on Ether, you need to be involved in merging to test as well. This is the only real way to make sure your project doesn't break while we're doing this. To that end, my colleague Sajida has put together a merge testing leaderboard to keep track of who's doing the testing.
Mainnet Shadow Forks
Since I last wrote on the topic of merge testing, we have completed 3 mainnet shadow forks, one of which was done in Amsterdam.
Mainnet shadow forks are an excellent test of the merging mechanism and client readiness. They are more or less equivalent to merging the mainnet (although the Ether Foundation and the development team currently control all the validators, which makes shadow forks a little easier). Shadow forks are too cool for me to go into all the details, but in general, as of now, these tests have been a huge success.
The first mainnet shadow fork occurred on April 11, and the following is a summary from Pari.
Marius announced that the shadow fork was a great success, a configuration issue related to gas limitation was found in the Geth client during testing, but the problem was not serious, there were various issues with different clients, but they were found and fixed.
The second mainnet shadow fork occurred during the Devconnect conference on April 23, and the following is a summary from Pari.
This is the first shadow fork where every client survived the merge and managed to stay in sync afterwards, and we're making real progress here!
The third mainnet shadow fork happened on May 5, and this test also passed very well.
More information you can find in the developer conference call transcript.
It includes some new tests on merge synchronization, which found some issues, but they are definitely fixable.
In addition, the Goerli test network has been shadow forked 4 times.
Most importantly, we are planning to merge three existing ethereum testnets in June: Ropsten, Sepolia and Goerli.
Beacon Chain Milestones
As of today, over 10% of ETH is pledged in the Eth2 deposit contract. hildobby.eth assembles a great deposit dashboard that shows the status and history of pledged deposits. The number of active verifiers is now close to 370,000 and growing faster than ever before.
Also, we have some good news in terms of client diversity, Prysm's market share is now less than 50%, which is a much healthier state for the entire beacon chain. In the previous months, Prysm's market share was over 68%, which is a very unstable situation. It seems like it would really help to write some warning articles, but seriously, hats off to the individuals and institutions that have defied the odds and invested time and effort to make changes, because of you Ether is stronger and more secure.
Of course, the battle isn't over yet. The next thing to improve is the diversity of implementation clients, which is even worse than the diversity of previous consensus clients.
Pledges
The pledge page on ethereum.org has been completely revamped and is very nice.
And while Lido has come under some scrutiny recently, Lido is doing exactly the right thing as a tool with a 30%+ share of the pledge market. This seems to have triggered a flurry of transparency. the next chapter of Lido is the updated decentralization roadmap I requested in early March. Beyond that, they share Lido's operator strategy. superphiz has some thoughts on all of this.
Also from Lido, they published an article titled Modeling The Entry Queue Post-Merge, which analyzes how merging might affect Lido's social reward model in the case of very long verifier activation queues.
As for Rocket Pool, Bits Be Trippin gave an overview of Rocket Pool in an interview with Darren Langley, and Rocket Pool announced support for Besu and Nethermind as Eth1 clients in its latest beta release. Yay, client diversity!
Welcome to join #NowhereDAO, a free information and token information sharing platform
No activity yet