Fraud Proofs vs Validity Proofs
In this article, we conduct an analysis and comparison of various Layer-2 (L2) scaling solutions, focusing on the differences between fraud proofs and validity proofs. Our thesis asserts that validity proofs have a fundamental advantage as they ensure only a correct state transition is accepted.
In recent months, several interesting attempts have emerged to address Ethereum's scalability issues, such as projects like Truebit, Gluon Plasma, dFusion, Roll-Up, and Ignis. The core idea is simple: instead of recording numerous transactions on the blockchain, there is a creation of a proof that a compressed representation (e.g., hash) of these transactions reflects a new state of affairs.
All the mentioned projects are L2 solutions, defining a protocol (and logic) that operates on top of Layer-1 (L1) and relies on it for various services: deposits/withdrawals, a registry for executing off-chain commitments, and as a "universal clock." It is important to note that L1 does not use the logic of L2, thus cannot apply it.
We aim to present a structure for comparing these solutions, with a particular focus on the differences between fraud proofs and what we will refer to as validity proofs. Essentially, fraud proofs and validity proofs can exist at the L1 level, but current attempts, and consequently our analysis, are at the L2 level.
The primary advantage of fraud proofs is that they are not required for every state transition but only when something goes wrong. Thus, they demand fewer computational resources and are better suited for environments with limited scalability. The main drawback of these protocols stems from their interactivity: they anticipate a "conversation" between multiple parties. This conversation requires the presence of parties, notably the party claiming fraud, and allows other parties to interrupt the conversation in various ways. However, the crux of the problem lies in the fact that the protocol interprets silence (lack of objections to a new state) as implicit consent. Indeed, a malicious actor can attempt to create the appearance of silence through DDoS attacks.
Let's describe a conceptual protocol: since a block can contain an incorrect transition to another state, the Fraud Proof protocol provides a time window — the Dispute Time Delay (DTD) — to dispute this incorrect state. This window is measured in blocks. If no fraud proof is provided within the DTD, the transition to the L2 state is considered correct. If a fraud proof is submitted to the smart contract and recognized as valid (i.e., provided within the DTD and indeed proves an incorrect state transition), this leads, at a minimum, to the smart contract reverting to the commitment of the last correct L2 state. Additional steps, such as penalty sanctions against the offending party, may be applied.
The choice of the DTD duration is significant: the longer it is, the higher the probability of detecting an incorrect state transition — which is good. However, the longer it is, the longer users are forced to wait, for example, for fund withdrawals — which is undesirable.