Full Report
The term proof is used for loosely in the blockchain industry. Originally with Bitcoin, proof of work was used as an anti-spam technique. It relies on the probabilistic assumption takes a certain amount of time to find the correct pre-image of a hash. Hashes are sufficiently random so this is fairly reasonable. Based on all previous data, there's no reason this won't work in the future. It makes this for deductive than inductive. Proof of Stake was popularlized by Tendermint. "Proof" relies on a majority of cryptographic validators (two-thirds power). With proof of stake, the current block is grounded in the previous one. All though the name implies some mathematical deduction, this is NOT a regular proof. This makes all of the blocks sequential to the other blocks. Light clients follow the same logic, except they start with a trusted block that is provided at the beginning of the light client. Additionally, they can skip blocks with "Non-adjacent block verification" assuming that 2/3 from the most recent trusted block have signed on this block. Giuseppe doesn't like this. Why? Two large induction leaps are being made: Any validator holding 1/3+ of the voting power at block height H continues to behave honestly for N blocks. Validator from the first point is no longer trusted at H+N. Because the validator is trusted from Height H + N blocks, if they decide to be malicious for a period of time their proof is still technically valid! It doesn't matter that they were slashed on the other chain; it's still valid from the perspective of the light client. The consequences of not having perfectly sequential block validation is not great given the argument. But, to my knowledge, no hacks surrounding this have happened yet. According to the author Skipping verification for non-adjacent blocks might very well be named "Proof of Faith" or, better, "Proof of Nothing". Interesting post around the design of Tendermint light client verification!
Analysis Summary
# Research: Proof of Nothing: Inductive Reasoning Considered Harmful
## Metadata
- **Authors:** Giuseppe (sbudella)
- **Institution:** Independent / Altervista Security Blog
- **Publication:** [sbudella.altervista.org](https://sbudella.altervista.org/blog/20250417-proof-of-nothing.html)
- **Date:** April 17, 2025
## Abstract
This article provides a critical analysis of the "Proof" in Proof of Stake (PoS), specifically focusing on the Tendermint light client verification protocol. The author argues that while original Proof of Work (PoW) and sequential PoS verification are deductive and mathematically rigorous, "Non-adjacent block verification" (skipping blocks) relies on flawed inductive reasoning. By analyzing the trust assumptions required to skip blocks, the author contends that this optimization—often termed "bisection"—undermines the cryptographic security of light clients, reducing the "proof" to a form of "Proof of Faith."
## Research Objective
The research aims to expose the logical vulnerabilities in the Tendermint light client’s ability to verify non-adjacent blocks. It addresses the question: *Is the trust jump made when skipping intermediary blocks mathematically sound, or does it introduce unacceptable security assumptions?*
## Methodology
### Approach
The author uses a logic-based analytical approach, contrasting **Deductive Reasoning** (where conclusions follow necessarily from premises, as in PoW and sequential PoS) with **Inductive Reasoning** (inferring future behavior from past observations).
### Dataset/Environment
- The theoretical specification of the **Tendermint Light Client**.
- The **CometBFT (formerly Tendermint) Rust implementation** (`tendermint-rs`).
### Tools & Technologies
- **Tendermint Testgen:** A library for generating mock blockchain structures for testing.
- **Rust:** Used to write a proof-of-concept test case demonstrating how verification fails to maintain rigorous trust when dealing with untrusted validator sets.
## Key Findings
### Primary Results
1. **The Inductive Leap:** The author identifies that skipping blocks requires assuming a validator holding 1/3+ voting power at block height $H$ remains honest until height $H+N$, without verifying the intervening blocks.
2. **Trust Paradox:** There is a logical contradiction in trusting a validator's signature to verify a new block at $H+N$ while simultaneously declaring that the validator's *new* voting power in that same block cannot be trusted.
3. **Ghost of Validity:** If a validator is slashed or becomes malicious on the main chain between $H$ and $H+N$, a light client skipping those blocks may still accept their signatures as valid because it lacks the "knowledge" of the intervening state changes.
### Novel Contributions
- **Conceptual Categorization:** Distinguishes between "Mathematical Induction" (which is deductive) and "Philosophical Induction" (which the author argues is the shaky foundation of modern light clients).
- **The "Turkey Illusion" Application:** Applies the classic philosophical "Problem of Induction" to blockchain consensus safety.
## Technical Details
In Tendermint, "Non-adjacent block verification" allows a light client to jump from Block $H$ to Block $H+N$ if:
- The block at $H+N$ is signed by validators representing > 1/3 of the voting power known at $H$.
- The time elapsed is within the "trusting period" (to prevent long-range attacks).
The author demonstrates via a Rust test case (`test_verify_inductive_voting_power`) that this logic is fragile. If a set of "Good" validators at height 1 are replaced by "Evil" validators at height 10, but one "Good" validator remains (even with minimal power), the protocol attempts to bridge trust across a gap where the actual security properties of the network may have fundamentally shifted.
## Practical Implications
### For Security Practitioners
- **Bridge Vulnerabilities:** Cross-chain bridges using light client verification may be susceptible to state proofs that are "technically valid" according to the light client logic but reflect a malicious state that was finalized during a "skip."
### For Defenders
- **Avoid Verification Skipping:** Where security is paramount (e.g., high-value bridges), defenders should favor **Sequential Verification**, even if it is slower, as it ensures a continuous cryptographic chain of custody.
### For Researchers
- **Failure Modes:** There is a need to formally model the "subjectivity period" and whether Bayesian inference can actually provide a safety bound for non-adjacent verification.
## Limitations
- **No Active Exploits:** The author acknowledges that, to their knowledge, no major hacks have specifically targeted this inductive "skip" logic yet.
- **Efficiency Trade-offs:** The article focuses on security rigor but does not provide a high-performance alternative to skipping blocks, which is necessary for resource-constrained light clients.
## Comparison to Prior Work
Traditional blockchain analysis treats "Proof of Stake" as a monolithic security model. This work differentiates between the **Base Consensus** (which is deductive/sequential) and the **Light Client Optimizations** (which the author argues are inductive and "Proof of Nothing").
## Real-world Applications
- **Inter-Blockchain Communication (IBC):** Tendermint's light client is the backbone of the Cosmos ecosystem's IBC.
- **Mobile Wallets:** Light clients are used in mobile apps where downloading the full chain is impossible.
## Future Work
- **Statistical Inference:** Exploring if classical or Bayesian statistical techniques can mitigate the risks of inductive leaps in light clients.
- **Slashing Proofs:** Investigating ways to "prove" malicious intent to a light client across non-adjacent blocks.
## References
- [Tendermint Light Client Specification](https://github.com/tendermint/spec/blob/master/spec/light-client/README.md)
- [The Problem of Induction (Wikipedia)](https://en.wikipedia.org/wiki/Problem_of_induction)
- [Tendermint-rs implementation](https://github.com/cometbft/tendermint-rs)