The Casper FFG manuscript connects conflicting finalized checkpoints to provable violations of voting rules. In its model, finalizing conflicting checkpoints requires at least one-third of stake to violate a slashing condition. The authors call this accountable safety: a failure leaves evidence attributable to particular validators. The paper also separates safety from plausible liveness. A chain can avoid conflicting finalizations while failing to finalize anything new.

Read the manuscript as a research design, including its historical proposal mechanism, rather than a verbatim description of today's Ethereum. A toy system with 300 equal stake units helps interpret the result: the theorem concerns an overlapping group responsible for inconsistent finalization, not a probability that an attack occurs. It does not show that every attacker values the stake more than every possible outside benefit. Security reasoning must preserve the conditional statement and the enforcement assumptions.

Replacing them with a claim that a rational attacker will never try discards the central point of the model.

Ethereum's proof-of-stake documentation describes votes linking checkpoints and distinguishes finalized history from ordinary block inclusion. Validators' influence is weighted by stake. Counting wallet addresses, machines or validator names is therefore not a substitute for measuring the relevant voting weight. Economic penalties make conflicting behavior costly, while fork choice and checkpoint rules determine what a node recognizes as the chain.

Imagine a block explorer reports a payment in the latest block. The useful follow-up is whether that block is part of finalized history, not whether a familiar validator proposed it. For a learning exercise, draw three states: submitted, included and finalized. Mark which node observation supports each state and what could still change. Then add a bridge that requires its own verification and delay. The source chain's finality does not automatically prove the bridge contract is correct or that its external custody is solvent.

A precise application status should name the assurance it has actually observed.

CometBFT's versioned consensus specification describes rounds with proposal, prevote and precommit steps. A commit requires more than two-thirds of voting power, while locking rules constrain later votes. These are rules for a consensus engine; the surrounding application's staking and penalty machinery is a separate design question. Do not infer an identical economic penalty just because two systems both use a two-thirds threshold.

For an illustrative fixed set of 100 equal voting units, any two groups of 67 overlap in at least 34. That arithmetic explains why incompatible certificates require overlap, but the protocol's vote and lock rules determine when overlapping participation is actually a violation. Now let 40 units become unreachable. The remaining 60 cannot form that quorum, even if all behave honestly. This distinguishes a safety argument from an uptime promise.

When reading a network's performance claim, inspect what happens under delayed messages, unavailable proposers and changes in the validator set, not only its best-case time to commit.

Ethereum's weak-subjectivity explanation addresses a different problem: a new or long-offline node may encounter an alternative history signed using old validator keys. If the relevant stake has already been withdrawn, historical signatures alone do not recreate the original economic exposure. A recent trusted checkpoint supplies an initial reference, after which the node verifies subsequent state according to the protocol.

This boundary matters when evaluating statements such as anyone can independently verify everything from scratch. Identify how a joining node obtains its checkpoint and how it checks that reference against independent sources. Also distinguish accepting a checkpoint from resolving a genuine conflicting-finality failure, which can require coordination beyond routine fork choice. For an exercise, describe the evidence available to an always-online node and a laptop returning after a long absence. Their data may be cryptographically valid yet insufficient in different ways.

Economic finality remains meaningful, but only when the operational assumptions about time, stake and chain selection are kept visible.