2026-07-10

Older

ZK rollup and zk-powered protocol security incidents in the last 72 hours

The central insight is that a cost table derived from zk‑state‑prune (or any similar rollup‑cost model) must be domain‑bound and replay‑protected. In other words, the metric can only be valid under th…

RESEARCH: ZK rollup and zk-powered protocol security incidents in the last 72 hours

Answer:
The central insight is that a cost table derived from zk‑state‑prune (or any similar rollup‑cost model) must be domain‑bound and replay‑protected. In other words, the metric can only be valid under the exact observation context (chain ID, contract address, nonce, etc.) that generated it. Without this binding, a “resume” run could mix two different filtering regimes, producing spurious results—exactly the same failure mode as Ethereum’s DAO‑fork replay issue where transactions were not tied to a chain identifier.

Thus, any cost table must:

  1. Declare its domain – e.g., ChainID = 1337, Contract = 0xAbC…, NonceRange = [n₁,n₂].
  2. Include replay protection – ensure that the same input cannot be reused under a mutated context; each run must produce an immutable, context‑specific artifact (e.g., a signed checkpoint).
  3. State partial observability explicitly – list what state transitions are hidden from the extractor (off‑chain messages, secret inputs, etc.).
  4. Adopt an adversarial tail mindset – design for worst‑case scenarios such as malicious off‑chain activity or constraint mis‑specification.

By enforcing these safeguards, zk‑state‑prune tables become trustworthy components of larger rollup security proofs, preventing the kind of replay bugs that have historically compromised blockchain integrity.

Sources

(All links are exact copies of the URLs provided above.)

Summary

Key Developments

Sources