Recommended this week
The pledge participation questionnaire is almost over (https://docs.google.com/forms/d/e/1FAIpQLScxNDWegcIIL9ogSL5yhRZgl3_fQclDnMic5wVSRyLfXeohEw/viewform). If the reader is running their own validator node (whether it is running on their own hardware or in the cloud): We hope to receive your pledge running experience.
Not only has Lodestar launched on the mainnet, but it is also running very well?
At the core developer conference this week, we gave the green light to the deployment of Altair’s upgrade. As a reminder, Altair introduced changes in the calculation of the synchronization committee and verifier revenue, but not The Merge.
Protolambda, the king of visualization, has done some amazing work to clear the way for deployment and upgrade. The last obstacle is: the participation rate of the synchronization committee on the testnet is very low (dropped by about 70%), and we don’t know why. Fortunately, Proto published an analysis that revealed a series of easy-to-solve problems. The most notable one is that the participation rate of the Nimbus synchronization committee is almost zero. This reason is really interesting.
We set the upgrade/fork time on Wednesday, October 27th. The specific epoch is 74240, which is 10:56:23 UTC on the 27th. We originally joked to pick a palindrome number (that is, epoch 74247), but for technical reasons, it is better to give priority to the former (epoch 74240 is the boundary of the batch processing history state root).
The client team will release a version of the mainnet compatible with the Altair upgrade at the end of September, and will publish some blog posts and publicity from October 4th. Please plan to update your client in the first few weeks of October.
Regarding other news, the excellent Pintail wrote a great analysis, predicting how the income of validator nodes will change after the Altair fork. The main points of the article are: the penalty for delaying the proof will be more severe; and even for the validators who perform perfectly, the rewards will be more different. The latter is due to the fact that randomly assigned tasks (proposed blocks and synchronization committees) account for a larger proportion of rewards than it is now.
Most of the updates regarding the merger are discussed at the core developer meeting.
An announcement in advance: A group of Eth1 and Eth2 teams will meet in early October to run some merged developer testnets. This will be the second time the eth1 and eth2 teams have worked together since the two teams worked together two years ago.
Client diversity is once again the topic of this week. The most recent discussion was caused by an analysis written by Michael Sproul of Sigma Prime.
Analyze the client distribution of validator nodes by collecting fingerprints on the block by Michael Sproul
Previously, there were only two known methods to analyze the network distribution of client types.
The first is to analyze graffiti to calculate the number of blocks produced by each client. This provides the client distribution information of the validator node. However, most of the pledgers (approximately 70%) changed the default settings of their graffiti, resulting in particularly large errors and very unreliable results.
The second method is to crawl the network to try to connect to the beacon node. As part of the information handshaking, the beacon node will report its client type, so it can analyze the client’s network distribution. However, there are several problems with this method, some of which we have discussed before. Even if we can accurately understand the distribution of nodes, this does not necessarily tell us the distribution of validators/stakes, because each node can host zero to thousands of validators. It can be found in the crawler dashboard of Miga Lab that this analysis method exaggerates the proportion of Prysm’s network in most regions. It may be because Prysm nodes host more individual pledgers (fewer validator nodes are hosted); and Teku is usually the choice of staking providers, so the proportion of its staker nodes in the network is underestimated. (Please note that Miga believes that their Singapore-based crawler gives very similar results to Sproul. Want to see the percentages on the Miga chart!)
Sproul uses a new technology to analyze the client’s network distribution, which is to “fingerprint” the block. The client contains up to 128 proofs when constructing a block. The order of these proofs is arbitrary and has no effect on the agreement. It turns out that different clients tend to use feature sorting. Through some analysis, you can know with certainty which client created which block. This is great, and for the first time we have a certain degree of accurate understanding of the client’s staking distribution. Of course, this has limitations: for example, the blocks built by Teku and Nimbus look similar, so it is not always possible to distinguish them. However, this kind of analysis is too useful, so I guess the client team will agree to code the different behaviors of the client to make the analysis results more accurate and effective.
Sproul’s research results confirm that Prysm continues to dominate the network, accounting for almost 2/3 of the total validator nodes. This caused a lively discussion. Since the block production accident occurred in April (the accident revealed that more than 70% of validator nodes are hosted by the Prysm client), the share of Prysm has dropped, but only a small part.
2/3 is really a terrible proportion, which is worrying. If an accident occurs and the node using the Prysm client is forked to another chain (such incidents have already occurred on the testnet), it is difficult to imagine how the beacon chain network can reasonably recover without using Prysm. Of verifiers caused huge losses. Adrian Sutton in his article “What will happen if there is a consensus failure in the beacon chain? “Explains why. This topic is also discussed on Reddit.
The discussion around this issue intensified: Dankrad published a post; Superphiz is launching an event to promote client diversity; Jonny Rhea made memes about client diversity; Evan Van Ness issued a very serious warning.
If you want to contribute your own strength as a solo staker, here is a guide to teach you how to switch from Prysm to Teku or Nimbus (please note my additional comments). Nimbus also published a migration guide.
If you are using a staking service provider for staking, then pester them on this issue until they diversify their client usage (migrate to a few clients), or at least stop adding new ones to the most used clients Verifier node.
You will not lose by using a relatively small client! Let me tell you that in this analysis of “Pledge Status in August 2021”, client C is actually Nimbus. Since the creation of Confident Standard Chain, Teku has always been the best performing client, and Nimbus has followed closely behind. In fact, the client with the largest percentage currently has the lowest rate of return? ♂️.
Remind everyone that Rocket Pool, a decentralized staking pool, will be launched on the mainnet on October 6. LogicBeach produced a one-minute video explaining Rocket Pool’s mainnet launch. The beacon chain browser Beaconcha.in has added RocketPool’s dashboard and verifier information.
Here is a not-so-simple paraphrase article: “Feist-Khovratovich Technique for Fast Calculation of KZG Proof” by Alin Tomescu. This article (slightly) analyzes the paper by Dankrad Feist and Dmitry Khovratovich on the implementation of ultra-fast polynomial commitments. I mention it here because this technology makes the planned shard chain data availability sampling scheme feasible. You can check my implementation in C language (this is based on Proto’s implementation in Go language, and it is based on Dankrad’s implementation in Python). Anton Nashatyrev is trying to integrate this technology into Teku as an Eth2 shard prototype.
Sina Habibian has released a new podcast “Into the Bytecode”. In the second period, Danny Ryan and Tim Beiko depth study of the etheric Square future agreements. I haven’t found a chance to listen, but I believe the content of this issue is definitely great.
Through actual implementation, the security of BLS batch verification is discussed.
Under PoS, the (minimum feasible issuance) target set by Ethereum was analyzed and some interesting observations were made.
The 73rd meeting was held on September 23
- Conference video
- My shorthand.
The discussion included Altair’s upgrade plan, regular updates of the client team, The Merge’s API, and client diversity indicators.
Core Developer Conference
The 122nd core developer meeting was held on September 17. Tim Beiko took notes, here is the meeting agenda. In addition, there are some discussions about The Merge.
Everyone agreed that the order of information on the consensus layer was initially set to be synchronous, and it may develop in the direction of asynchronous in the future.
Everyone (more or less) agreed to hard-code the terminal total difficulty of the PoW chain. This reduces complexity and enhances security, but there are some trade-offs (discussed in the meeting and summarized in the notes).
There is a question raised around “transaction type representation”, which is too subtle for me to understand.
The client team reported on its update to The Merge’s implementation process.
Stakehouse community meeting
StakeHouse focuses on building tools to lower the technical threshold of staking and promote the healthy development of the beacon chain.
The seventh community meeting of Stakehouse took place on September 15th. Here is the summary post, as well as the conference video.
In the meeting, a great Stereum demo was shown, which is a free graphical environment for setting up and monitoring staking nodes. They enable a fast sync version for all clients.
There is also a demo of Wagyu Keygen, which is a graphical tool for key generation and deposit and pledge. The first version of Wagyu Keygen has been released) (Only online on testnet). They are collecting feedback from users who participated in the test-participants can claim POAP.
As always, StakeHouse continues to discuss project updates and its list of project ideas.
If you are a BrightID user, they are airdropping their $BRIGHT tokens fairly. For example, if you previously set BrightID for GitCoin verification, then you may be eligible to apply for an airdrop. In addition, holders of Eth2 beacon chain genesis pledge POAP are also eligible to apply for some $BRIGHT tokens. To be honest, the process is a bit cumbersome, but in the end I managed to claim a bit.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/eth2-progress-update-as-of-2021-9-24/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.