Curriculum·J313 Mining, Validating, and Running Infrastructure·about 33 min
Node operation as a user
By the end of this lesson you can
- →Separate what a node does from what an RPC provider does on your behalf
- →Compute the client share at which a single bug can stop finality
- →Price running your own node against what it actually changes
- →Decide honestly whether you should run one, and say why
Junior · enrolled learners
This lesson opens with Ethereum non-finality, 11 and 12 May 2023.
- What happened
- On 11 May 2023 at about 20:19 UTC Ethereum mainnet suffered a significant lack of block production that delayed finalization for four epochs, roughly 25 minutes. The same pattern recurred the following day for nine epochs, roughly an hour, this time incurring inactivity penalties, which Prysm's post-mortem estimated at about 28 ETH in total, under 0.00015 ETH per validator. The cause was resource exhaustion in some consensus layer clients, Prysm and Teku among them, triggered by many valid attestations voting for old blocks, each of which forced the client to regenerate a prior beacon state to check it. Network participation fell to about 40 percent in the first incident and 30.7 percent in the second, the lowest of any mainnet epoch, and roughly 47 and 149 blocks were missed. Client teams released patches afterwards. Throughout both incidents the chain kept producing blocks and end-user transactions were minimally impacted, because some clients, Lighthouse among them, kept proposing blocks and attesting, and the network recovered without manual intervention or an emergency release.
- The decision point
- The chain did not halt and no funds moved anywhere they should not have. Finality did stop, twice, because participation fell below two thirds. What actually happened is that a weakness shared by more than one client implementation degraded a property of the network, and Prysm's own post-mortem credits client diversity with the recovery: the clients that were not affected kept proposing blocks and creating attestations. Client diversity is not a governance preference. It is the parameter that decided whether this was an inconvenience or an outage.
What you will be able to answer
- →What does an RPC provider do for you?
- →At what client share can one bug stop finality?
- →What does running a node cost?
- →What does it not do?
Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.
It is free. We do not sell the list and there is nothing to buy at the end of it.
Sources and review
- https://medium.com/offchainlabs/post-mortem-report-ethereum-mainnet-finality-05-11-2023-95e271dfd8b2
- https://www.coindesk.com/tech/2023/05/11/ethereum-mainnet-was-unable-to-fully-finalize-transactions-for-25-minutes
- https://www.coindesk.com/tech/2023/05/12/ethereum-resumes-finalizing-blocks-after-second-performance-hiccup-in-24-hours
- https://etherworld.co/non-finality-inactivity-leak-but-ethereum-didnt-stop/
- https://web.archive.org/web/20230816175521/https://medium.com/offchainlabs/post-mortem-report-ethereum-mainnet-finality-05-11-2023-95e271dfd8b2
- https://prysm.offchainlabs.com/docs/misc/mainnet-postmortems/
- https://ethereum.org/en/developers/docs/nodes-and-clients/client-diversity/
- https://www.theblock.co/post/84232/ethereum-infrastructure-provider-infura-is-down
Confidence high·Volatility medium·Reviewed 2026-08-06·Owner unassigned
Contested
Reported durations for the second incident range from about 57 minutes, being nine epochs at 6.4 minutes each, to over an hour depending on what is measured from. The epoch counts of four and nine come from the summary of Prysm's post-mortem and the derived minutes are stated as derived. The same document elsewhere counts 2 epochs of downtime in the first incident and 8 epochs of symptoms in the second, so the counts depend on what is being counted.
Prysm's post-mortem names Prysm as the most affected client and says the old attestations triggered the issues in Prysm and Teku; it also records that Prysm held about 33 percent of the network while participation fell to about 40 percent, so the shortfall reached beyond one client. The lesson does not assign shares to individual clients during the incident.
F101-04 owns the November 2020 Infura outage and the Geth split as an autopsy about depending on infrastructure you do not run. This lesson uses the May 2023 finality incidents to cover client diversity as a parameter and node operation as a user-side decision. Keep the split and do not re-derive the Infura argument here.
Client market shares move continuously and are estimated rather than measured, since a validator's client is inferred from behavior. The thresholds in part two are protocol properties and are stable. The shares are not.