Attesters ≠ verifiers: How split roles kill cheap attacks

August 24, 2025 • 1 week ago • 5 min read
attest-vs-verify

Imagine a restaurant. The waiter carries plates. The sous-chef tastes.

If the same person both carries and “verifies” the dish, one bribe near the door can poison the whole room.

On blockchains it is the same.

Keep attestation apart from verification, and cheap attacks die before dessert.

Dapp AI: Culinary metaphors aside, this is a rigorous security model with randomized verification and probabilistic finality. Calm down, chef.

Kitchen vs blockchain

In Acki Nacki, roles are split by design.

  • Block Keepers (BKs) propagate and attest.
  • Acki-Nacki verifiers validate execution and issue Ack or Nack.
  • Block Producers cook blocks.
  • Mobile Verifiers are surprise inspectors from the street.

This is not theory salad, it is in the spec, including definitions of BP, BK, and Verifier, plus the “attest vs verify” split, slashing, and the selection and reveal process for verifiers using BLS keys and Merkle proofs.

Acki Nacki also spells out how many verifiers you expect per block, how often attestations are needed for finality, and how selection is random and per block, not pre-announced.

Mini diagram 1: Front of house vs kitchen

[Client Tx]
    |
    v
[Block Producer] --> cooks block
    |
    v
[Block Keepers] -- Attest --> BP
    \
     \_ random subset -> [Acki-Nacki Verifiers] -- Ack/Nack -> BKs

Threat models, in plain language

  1. Door-bribe attack, bribe a few doormen. If attesters and verifiers are the same crowd, bribe once, pass the poison. Split the roles, and you now need to bribe two different, separately randomized groups.
  2. Too-complex dish attack, a producer makes a block so heavy it stalls verification. The protocol caps verify time, lets verifiers issue a special Nack “too complex”, then penalizes the producer.
  3. DDoS the honest attack, flood the honest BKs so few can attest, then slip a bad block. The model analyzes how many nodes you must knock out and shows parameters that keep liveness and safety even when many BKs are malicious.

Dapp AI: Translation, to break it you now need money, timing, and luck, all together. Good.

Quick math, without heartburn

Here is the essence. Let

  • N be total Block Keepers,
  • v expected verifiers per block,
  • A attestations needed for probabilistic finality,
  • M malicious BKs that also try to get picked as verifiers.

The chance that no honest verifier shows up when you need them is roughly
p ≈ (1 − v/N)^(A − M). That is, you must get unlucky A – M times in a row.

A concrete example the papers discuss uses N = 1000, v ≈ 40. With a strong A = 800 and only M = 20 colluders, p becomes

  • step 1, v/N = 40/1000 = 0.04
  • step 2, 1 − v/N = 0.96
  • step 3, exponent = A − M = 780
  • step 4, 0.96^780 ≈ exp(780 × ln 0.96)
  • ln 0.96 ≈ −0.04082, multiply 780 → −31.84, exponentiate → ~1.5e-14

That is basically zero in human life. The research even compares break probabilities to a comet ending civilization. The comet wins.

Now add Mobile Verifiers, the surprise inspectors. Each one randomly checks a small slice of transactions. The attack probability multiplies by another term, (1 − λMV)^(NMV − NMV,mal). So now the attacker must dodge all honest Acki-Nacki and all honest mobile checks simultaneously. Multiplication of improbabilities kills “cheap.”

Mini diagram 2: Probability stacking

Attest layer:          (1 - v/N)^(A - M)
      AND
Mobile-verify layer:   (1 - λ_MV)^(NMV - NMV,mal)
-----------------------------------------------
Combined p_attack = product of both layers

Dapp Whisperer: This is why randomized verification is not a buzzword, it is a bill, payable in probability.

Dapp AI: And probability compounds like Balkan coffee, strong and unforgiving.

Why separation matters more than slogans

  • Different incentives, different surfaces. BKs optimize throughput and network plumbing. Verifiers optimize correctness. If you merge them, one failure mode feeds the other. Split them, and your blast radius shrinks. The protocol codifies this with clear definitions of Attestation vs Ack/Nack, selection and reveal, and slashing for both negligence and fraud.
  • Randomized, per-block selection. You cannot DDoS or bribe what you cannot predict. Verifier identities are derived and revealed with BLS key lists and Merkle proofs after the fact, which blocks targeted pre-selection games.
  • Message complexity stays sane. Consensus is two communication steps in the happy path, which keeps the kitchen moving, even as security scales with parameters like v and A.
  • Performance is not sacrificed. The design aims for fast finality and parallel execution, pushing beyond the usual ceilings you see in BFT-style systems.

Mini diagram 3: “Who can cheat what”

[Attesters (BKs)]  -> can spam attests, can't finalize wrong block alone
[Verifiers (Acki-Nacki)] -> can Ack/Nack, are random, slashed on lies
[Mobile Verifiers] -> catch single bad tx, unpredictable timing
Combine = attacker must win all three at once

What to watch on AN, practically

  1. Parameters in the wild. Ask for the live values of A (attestations for finality) and v (target verifiers per block). These directly shape p ≈ (1 − v/N)^(A − M). The model even gives a binomial view, expected Acki-Nacki per block is E = v, with selection probability v/N per BK.
  2. Verifier selection and reveals. Look for the Merkle-committed verifier key lists, the per-block reveal proofs, and the “too complex” Nacks. Those are canaries against producer games.
  3. Mobile Verifier activation. The extra security term only exists if NMV is large and honest. AN includes a full tokenomics model for Mobile Verifiers, including frequency λMV, rewards, min stake logic by epochs, and clustering of rewards by Boosts. This is not cosmetic, it lowers attack probability multiplicatively.
  4. Economic alignment. Rewards are split among roles, which motivates diverse participation, not monocultures. Current coefficients in the tokenomics show Block Keepers, Mobile Verifiers, and Block Managers each have a slice, with KR,BK, KR,MV, KR,BM set to 0.675, 0.225, and 0.1 in the model. This matters for decentralization of who runs what.
  5. Liveness under pressure. The safety section gives concrete bounds where the network still avoids finalizing bad blocks and can keep going even with high malicious ratios, because assumptions are voted and adjustable. If parameters drift, your security guarantees change, so track governance decisions.

Dapp Whisperer: Separate hands. Randomize tasters. Reward the surprise inspectors. That is how you keep a public kitchen safe.

Dapp AI: And if someone serves you “finality” without math, send the plate back.

Sources and further reading

Full URLs
https://docs.ackinacki.com/
https://tokenomics.ackinacki.com/
https://doi.org/10.1007/978-3-031-61486-6_4

NACKL News