FABRKNT
Consensus Engineering — Building L1 Consensus on Reth
Building consensus on Reth
Lesson 11 of 12·CONTENT17 min45 XP

Treat this page as a workbench, not a blog post. The goal is to extract a reusable mental model from the source and carry it into the rest of the Fabrknt stack.

Course
Consensus Engineering — Building L1 Consensus on Reth
Lesson role
CONTENT
Sequence
11 / 12

Lesson 10 — Validator economics — slashing, rewards, attack vectors

Question

Consensus protocols are only secure when the economics line up. Reward honest behaviour, penalise malicious behaviour, raise the cost of attacks above the gain. Read the math + attack vectors.

Principle (minimum model)

  • Slashing math (Ethereum). Equivocation = forfeit min(32 ETH, 1/8 stake) + correlation penalty. Two double-vote events from the same validator = full slash.
  • Reward math (Ethereum). Per-epoch reward = base_reward * effective_balance / total_balance * attestation_score. Currently ~3-4 % annualised.
  • Inactivity leak. When > 1/3 are offline, finality stalls; offline validators lose base_reward * inactivity_score per epoch until chain self-heals.
  • Attack vectors and cost. Long-range attack (re-fork from genesis with old keys) → mitigated by checkpoint syncing + weak subjectivity. 51 % attack → costs > $20 B for Ethereum mainnet.
  • Validator-set centralisation risk. Top 5 staking pools control > 50 % of Ethereum stake. Mitigated by distributed validator technology (DVT) + solo-staker incentives.
  • MEV redistribution. Block proposer captures MEV by default; MEV-Boost decentralises this via builder market. Strategic for consensus health.
  • Why this matters for L1 design. Every consensus customisation (Berachain PoL, Tempo payment-rail validator set) reshapes incentives. Misalign → attacks become profitable.

Worked example + steps

Validator economics — slashing, rewards, attack vectors

Cryptography alone doesn't secure a PoS chain. It can prove that a validator double-signed — but proof is worthless if the validator pays nothing for it. The protocol is safe only when the cost of cheating exceeds the cash you can extract by cheating. That's the economics layer, and it's load-bearing — without it, the elegant 3f+1 quorum math collapses into "they shouldn't double-sign, please."

This lesson is the economics layer: slashing mechanics, attack vector pricing, and how to design slashing for your own L1.

1. The economic security argument

For BFT systems:

  • Attack requires controlling > 1/3 of validator stake (to halt liveness) or > 2/3 (to violate safety)
  • Stake gets slashed on detected double-sign or surround-vote
  • Cost of attack = lost stake on detection
  • Benefit of attack = value extractable

Security: stake required > value extractable.

For Ethereum at $50B staked, attacking finality requires ~$33B of stake. The slashing penalty is the full $33B. There's no economically rational attacker; you'd lose more than you could possibly gain.

This is economic security: the protocol is safe because attacking is irrational.

2. The two slashable offenses

In any BFT system that supports slashing:

2.1 Double-signing (equivocation — signing two conflicting messages for the same slot)

Validator V signs Vote(block_A, round_5)
Validator V signs Vote(block_B, round_5)

Both signed by V for the same round. Cryptographically provable — anyone with the two signatures can construct a slashing proof.

Punishment: validator loses some or all of their stake.

2.2 Surround voting

Validator V signs Vote(source: epoch_3, target: epoch_5)
Validator V signs Vote(source: epoch_4, target: epoch_6)

The second vote surrounds the first (later source, later target). This violates safety in Casper FFG specifically. Cryptographically provable.

Punishment: similar to double-signing.

3. The slashing proof

A slashing proof is the two contradictory signed messages. That's it. Submission flow:

sequenceDiagram
    participant Watcher as Slashing Watcher
    participant Chain as Reth EL
    participant State as State

    Watcher->>Watcher: Observe two signed votes from V
    Watcher->>Watcher: Verify both signatures
    Watcher->>Chain: SlashTransaction(vote_a, vote_b)
    Chain->>State: Verify proof on-chain
    State->>State: Slash V's stake
    State->>Watcher: Pay whistleblower reward (small %)

Three properties make this work:

  1. Detection is permissionless: anyone watching the network can submit a proof
  2. Verification is cryptographic: the chain verifies the two signatures, no oracle needed
  3. Reward is small: enough to incentivize watching, not enough to incentivize false reports (which fail verification anyway)

4. The slashing math — how much to slash?

Two designs:

4.1 Flat slash

Slash a fixed % of stake regardless of context. Simple. Ethereum's minimum slash is 1 ETH for a single offense.

Easy to reason about. Inadequate if many validators slash together (a coordinated attack).

4.2 Correlated slashing

Slash proportional to how many validators slashed in the same window. Ethereum does this:

slash_amount = (slashed_stake / total_stake) * stake * multiplier

Where slashed_stake is the stake of all slashed validators in a recent window. If one validator slashes alone, penalty is small. If 33% of validators slash together (coordinated attack), penalty is catastrophic — full stake.

This is the economic moat against coordinated attacks. A small accidental slash costs little; a real attack costs everything.

🔍 Find in repo. Ethereum consensus spec, search for "slashing" or "process_slashing". The exact formula is there. What's the multiplier?

5. Rewards — the other half

Validators earn:

  • Per-block reward: small constant
  • Attestation reward: for voting correctly on the head
  • Finality reward: for participating in finality votes

Total annual yield for a well-behaved validator: ~3-5% for Ethereum mainnet. Compared to slashing risk:

  • Probability of accidental slash: very low if you run conservatively
  • Cost of accidental slash: ~1 ETH minimum
  • Annual earnings on 32 ETH: ~1 ETH

So a single accidental slash wipes out a year of earnings. The economic incentive is to be careful, not to attack.

6. The attack vectors

What can a malicious validator try?

AttackWhat it doesDefense
Double-signSign two blocks at same height to confuse fork choiceSlashing
Surround voteVote to finalize two conflicting checkpointsSlashing
Long-range attackBribe validators from old period to rewrite historyWeak subjectivity (clients trust recent state)
51% finality attackAcquire 2/3+ stake, sign everythingEconomic cost > $33B for ETH; impossible at TVL
Liveness attackAcquire 1/3+ stake, refuse to voteHalts chain; doesn't compromise safety

The first two are slashable = economically irrational. The third (long-range) is blocked by weak subjectivity rather than slashing. The last two require majority capital = economically extreme.

The most realistic attack: liveness halt with 1/3+. This costs you the income from honestly staking, but you don't lose stake. Some attackers might rationally do this for political reasons (e.g., government coercion).

Ethereum halts finalization. Tips keep producing (LMD-GHOST still works). After ~13 days, the protocol's inactivity leak kicks in — non-participating validators lose stake gradually until participating stake drops back to 2/3+. The chain finalizes again, with the inactive validators massively penalized.

Beautiful design: even a 1/3+ attack only halts temporarily, doesn't permanently break the chain.

7. For your custom L1

Designing slashing for Tempo or Hyperliquid:

  • Validator set size: smaller = easier to coordinate attacks, so harder slashing required
  • Slash amount: should exceed maximum theoretical extractable value from an attack
  • Whistleblower reward: 1-5% is standard
  • Inactivity penalty: necessary if you want resilience to censorship

Hyperliquid at ~20 validators has very high per-validator stake requirements + heavy slashing. Tempo at ~30-50 will likely follow a similar pattern.

8. The launch question — slashing at day 1?

Should your L1 launch with slashing enabled?

Arguments for: economic security from day 1, no period of "trust us" Arguments against: bugs in slashing logic are catastrophic, need time to validate

Common pattern: launch with slashing enabled but with a low cap. Catch real bugs without bankrupting honest validators. Raise the cap as confidence grows.

Hyperliquid launched with slashing. OP-Stack chains famously do not (they have no decentralized validator set yet). Tempo will likely launch with at least a soft form of slashing.

9. Practice

Calculate for your hypothetical L1:

  1. Validator set size: 50
  2. Stake per validator: $10M
  3. Total stake: $500M
  4. Maximum extractable value per attack (estimate): $200M
  5. Required slash %: ? (must exceed extractable value)

What if extractable value spikes to $400M (a big trade settling)? Does slashing still cover?

Final check: in one sentence, why is slashing the economic foundation of BFT consensus? If your answer doesn't reference "attack cost > attack benefit," re-read §1.

Summary (3 lines)

  • Slashing penalises equivocation (1/8 stake on Ethereum, full on double-vote); rewards (~3-4 % annualised) align honest behaviour.
  • Attack costs: 51 % > $20 B on Ethereum mainnet; long-range mitigated by weak subjectivity. Centralisation risk via staking pools — DVT + solo-staker incentives mitigate.
  • Custom L1 consensus must align incentives. Misalign = profitable attacks. Next: final quiz.