Mid-October Medalla Testnet Disruption: How It Started, How Will It End?
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
Ethereum enthusiasts (ID: ethfans)
, author: yorickdowne, translation: A Jian, reprinted by Odaily with authorization.
There was an accident on the Medalla testnet on October 17, 2020 (Editor’s Note: In fact, since October 14, 2020, the Medalla testnet has not finalized a block). So what happened? Here's a 5-year-old who can explain it too. (Probably not 5, but 10, but that's what it says.)
1) A bunch of validators are down (maybe due to participation in the zinken testnet, maybe because they got bored, who knows)
2) The Medalla test network has entered a state where blocks cannot be finalized.
3) Prysm client and Nimbus client began to have some synchronization bugs
4) We lost more validators because of this bug, some never heard from again
5) The network has no finality, which increases the memory and CPU burden of nodes, and makes us try many verifiers, because their nodes cannot handle such a large burden
6-1) Either a large number of verifiers come back online, allowing the network to regain finality; or
6-2) They don't come online, and then these offline validators keep losing their deposit faster and faster until we regain finality. In this process, some verifiers may also be kicked out of the team because the balance is too low
7) You can keep an eye on beaconcha.in for the latest web engagement rates. Other sites have largely failed to catch up
8) If this happens on the mainnet, it won’t last that long, because if the real ETH is burned, people won’t be so indifferenthttps://github.com/eth2-educators/medalla-exit
9) The entire network is working as it was designed to heal itself in scenarios of massive splits
10) If it is 6-2) In this case, I am not sure how soon the network can return to normal, the earliest may be October 25th, and the latest may be (25th) and then 5 days later
11) If you are offline, but don't want to go back and re-run the validator, here is a tool to help you exit the validator team in an orderly manner:
More technical details:
Validators who are inactive will not be penalized. A validator may remain in this inactive state because it is still in the activation queue, or its deposit has not been processed - these validators will be activated when the network regains finality. In addition, if an active verifier sends an active exit message, it will also become inactive and will not be punished.
Active and online verifiers will maintain a state of neither profit nor loss, if the packaging distance of their attestation messages is perfect 1 (that is, the attestation message sent in the previous slot will be packaged in this slot). But this is impossible, so they are punished slightly. The Ethereum Foundation's djrwto (that is, Danny Ryan) has stated that they are looking for a way to safely reduce the penalty for this part of the "dedicated" validator, because this penalty, in general, is not a good experience.
Active and offline validators are penalized quadratically, that is, the penalty increases every epoch.
A validator is considered offline when no attestation message is packaged within an epoch. Of course, this inability to submit attestations can also occur if a validator is connected to a beacon chain node that is out of sync with the network, or if the validator client itself is not working. Possible causes include client-side bugs and memory/CPU resource usage. You can also take the opportunity to learn how to compile the client from source and check the resource usage of your own nodes.
On the morning of October 12th, EST, we were in a state where we could not finalize the block. (The definition of this state is that 4 consecutive epochs cannot be finalized.)
From then on, the "square penalty" kicked in. The penalty for offline validators increases as the state of non-finality persists. The formula is penalty = effective balance * non-finality duration (Epochs-Since-Finality, that is, the height of the current epoch minus the height of the last epoch that obtained finality)/(2^25). Mathematically this can be said: the single epoch penalty for these offline validators increases linearly with the progress of the endless state, so the total penalty (sum of penalties) increases quadratically (thanks torfbolt for pointing that out).
It is difficult to estimate when the network will regain finality, as validator participation rates fluctuate in response to client failures.
If a validator's "effective balance" is lower than 16ETH (more than 16.75 ETH in the account balance), it will be kicked out of the validator team.
It takes about 18 days for a validator's balance to drop to 60.6%, which is the upper limit of time-consuming.Chinese translation）
After three more consecutive periods, finality will be re-established. Penalties for offline validators revert to their regular, less severe defaults.
