We had a small incident last week where engagement on the beacon chain dropped by around 8% in about an hour, after the incident we had a lot of discussion in the Discord channel and the devs checked who was missing After the block proposal, we soon found out that the accident was caused by Teku.
Figure: In an hour or so, the network participation of the beacon chain dropped by 8%
You can get the full picture of the whole thing in our after-the-fact report . To summarize, there was a massive spike in ETH deposits in the deposit contract in the hours leading up to the outage. The mechanism for agreeing on the state of the ETH 1 chain means that deposits are batched onto the beacon chain every 7 hours or so. And about 4,000 deposits in a short period of time exposed some poor performance of the Teku client in handling deposits, with some nasty cascading effects.
Thankfully, this issue was only temporary, and once the deposits were processed, network participation returned to normal. Also, there is no practical way to repeat the DoS attack on Teku clients: because making 4000 deposits is expensive! As explained in the comments, we’ve fixed initial performance issues and dug into the underlying structure to make the Teku client more stable in the future. The repaired version of the client is codenamed 22.3.2 , if you haven’t updated it yet, please update it as soon as possible.
Due to the small market share of Teku clients (less than 33%), the impact of this accident is minimal, and the beacon chain continues to move forward without stopping. If the clients with the largest market share are affected, the consequence will be a considerable period of non-finalization. This is bad for everyone, especially those running mainstream clients, as they get additional penalties for inactivity leak mechanisms (negative penalties).
To further emphasize the importance of client diversity, Dankrad recently published an article that delves into these issues . He wrote:
“If you’re currently running a Prysm client, there are very real concerns that you could lose all your funds and you should consider switching clients.”
More on Client Diversity:
- Freddy created a financial model that allows stakers to quantify the risks associated with running a majority of clients;
- rated.network has updated their frontend to show the client distribution per staking operator;
- Vans discussed client diversity at ETH Austin last week. I have tried to find a recording of this event but have been unsuccessful, please let me know if you have one.
- Dappnode is doing what it can! It now supports three clients on the Prater testnet, with Nimbus to be added shortly. This was expected, test it out, we’ll see it on mainnet soon;
Other Beacon Chain news: We are approaching a major technical milestone. As we all know, validator activations and withdrawals are currently limited to 4 per epoch, or 900 per day. Once the network has 327,680 active validators, this limit will rise to 5 per epoch, or 1,125 per day. This may not sound like a big deal, but it is actually a major change in the operation of the beacon chain. We should hit that milestone sometime next week.
The Ethereum Foundation made the much-anticipated announcement of the Kiln public merged testnet on March 14, and here’s the landing page .
The Kiln merger event took place shortly after 3pm GMT on March 15, and while a little less than ideal, it was ultimately a success. After the merger is complete, the unified chain continues to function and transactions are processed.
However, there were some problems with this process. During the last core developer call, we discussed them and summarized them as follows:
- There is an endianness divergence between Prysm itself and the execution layer , which prevents it from generating valid blocks. Since the Kiln testnet is configured with a fairly uniform consensus client, the impact is not large. But if the client distribution is similar to the beacon chain situation today, then this will be a significant problem. Here is Prysm’s event review .
- Some nodes of the Nethermind client crashed.
- Erigon also had some endianness issues.
Through this test, we learned some lessons. The number of clients involved has doubled, making it harder than usual for us to figure out what’s going on. Also, we are now used to blockchain explorers not being available.
The plan now is for the Kiln testnet to remain available as a public testnet, and everyone is encouraged to give it a try. It seems that Tenderly, Lido, and Uniswap are all on board, and if you want to make sure your stuff works flawlessly when merged, now is the time to test it out on the Kiln testnet.
Here are some tutorial resources on the Kiln testnet:
- How to run a node on the Kiln testnet ;
- Lodestar settings for the Kiln testnet ;
Devnet-6 and shadow forks
The testing effort will only intensify as the Kiln testnet is up and running. Another short-term devnet testnet (Devnet-6) will go live next week.
More interesting than the Devnet testnet are shadow forks. This is where we take the state of the existing network and mirror it to the merged PoS network. This means that tx from the real network can be replayed onto the shadow network when the merge happens. The Goerli network is the shadow fork network and is scheduled to repeat every two weeks. (The two networks gradually get out of sync due to transaction order issues, so the shadow network needs to be reinitialized from time to time for maximum effect.)
If both devnet-6 and the Goerli network shadow fork go well, we intend to do a shadow fork of the Ethereum mainnet within two weeks. Eventually there will be a shadow forked network updated daily for clients to amplify any potential problems.
After that, developers will consider migrating existing testnets to PoS, and you can track progress at wenmerge.com Would rush into it just because of that. Difficulty bomb is definitely a factor in the decision mix though.)
It now appears that implementing an ASCII art banner for merge events (thanks, Greg!) has been anticipated by many. Prysm and Lighthouse have implemented it, and if any ASCII art geniuses want to help Teku, we have an unsolved problem that needs help.
The two main themes of the post-merger network upgrade (the execution side is tentatively scheduled for Shanghai and the consensus side is tentatively scheduled for Capella) are still validator balance withdrawals, and so-called blob transactions.
As mentioned earlier, there is a validator withdrawal specification , which is the umbrella for enforcing changes and consensus changes. There are 3 EIPs that need to be discussed in terms of consensus:
- PR-2836 is the basis for driving withdrawals, i.e. from the beacon chain to the execution layer. (As far as I know, this will require those of us with legacy BLS withdrawal credentials (0x00 prefix) to update to 0x01 credentials before withdrawing. I haven’t seen a mechanism to do this update, although there is an open question.)
- PR-2854 is just an administrative update to reflect that this mechanism does not trigger EVM execution. It will only update the balance of the Eth1 account.
- PR-2862 proposes a mechanism for partial withdrawal of balances over 32 ETH. (This will automatically scrape excess balances from validators in a round-robin fashion and transfer them to the relevant Eth1 account at a rate of 256 validators per epoch, which is equivalent to roughly every 6 validators per epoch based on current numbers Experience once a day. The rationale for this frequency can be found here .)
The implementation side of these changes corresponds to EIP-4895 , and the good news is that there are no gas fees for withdrawals from validators to your Eth1 account, whether full or partial withdrawals.
As for the Blob transaction proposal EIP-4844 , it even has its own website (seeing the importance of this proposal). The site lists the Proto-Danksharding FAQ by Vitalik , and yes, proto-danksharding seems to be the new name for this upgrade.
R&D and regular developer conference calls
MEV remains an important factor driving the future development of the Ethereum architecture. There are major concerns about the current direction of travel, and I’m always happy to see alternatives being proposed. One such alternative is the Shutterized Beacon Chain , which describes a mechanism for processing encrypted transactions in Ethereum blocks.
The 84th Implementer Conference Call was successfully held on March 24.
- My shorthand content
The 134th core developer conference call was successfully held on March 18th.
- Notes from Tim Beiko ;
Topics: Kiln testnet online review; JSON RPC marked as “completed”, “secure” and “latest”; beacon chain withdrawals; proto danksharding (EIP-4844); coordination of EIP processes at the execution and consensus layers.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/lets-talk-about-some-problems-exposed-by-the-ethereum-merge-test/
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.