Validity Proofs vs. Fraud Proofs: An Explanation

Table of Contents

The exponential growth of Ethereum has brought both severe failures and promising futures for numerous sectors. DeFi and NFTs, for example, are the two of the many new, innovative ideas that have flourished. Moreover, the Ethereum and decentralized ecosystem is steadily growing with new applications. This rapid increase in network activity has also sparked a discussion between Validity Proofs and Fraud Proofs to resolve the layer-2 (L2) scalability issues.

Overview

Recently, lots of proof-based attempts, namely Truebit, Gluon Plasma, dFusion, Roll-Up and Ignis, have been made to solve Ethereum's scalability issues. The fundamental concept is quite straightforward, rather than adding a large number of transactions to the blockchain, one instead creates a proof that a brief summary (such as a hash) of these transactions accurately captures the new state of affairs.

Proofs are most frequently used in layer-2 blockchains, such as the aforementioned projects, which use rollups to gain scale and higher throughput while guaranteeing the accuracy of the underlying chain’s state. A roll up is a kind of scaling solution that groups transactions on a separate blockchain and employs proofs to guarantee the accuracy of the transactions.

There are two types of rollups, which are:

Optimistic Rollups: Assume that all transactions are legitimate, and apply fraud proofs to identify fraudulent transactions within seven days.
Zero Knowledge (ZK) Rollups: Immediately determine whether a transaction is valid or not using validity proofs.

Validity proofs and fraud proofs examine the validity of transactions before adding them to the state of the base chain.

Before diving deeper into the two types of proofs, it should be noted that Proof Systems (like SNARK and STARK) can be employed as Validity Proofs or Fraud Proofs. We should not confuse how we prove (e.g. SNARK, STARK) with what we prove (Fraud or Validity).

Fraud Proofs

A fraud proof (or fault proof) is a proof provided by a verifier that challenges a transaction state. Based on that, the fraud proof runs over a subset of the transactions and attempts to validate them.

Here's a quick explanation:

If the fraud proof detects an issue, the transactions in the batch are eliminated, and the batch is returned to a previously verified valid state.
If no proofs of fraud are produced during the dispute period, the state change is presumed to be correct.

Fraud Proofs provide proof that a state transition was wrong. They reflect an optimistic view of the world: the assumption is that blocks represent only valid states of L2 data until proven differently. In actuality, a committed block may contain an improper state transition.

The fundamental benefit of Fraud Proofs is that they are not required for every state transition, but only when things allegedly go wrong. As a result, they use fewer computational resources and are better suited to environments with limited scalability.

The main problem of these protocols is that they specify a "dialogue" between numerous parties. A dialogue needs the parties to be present (liveness), particularly the party asserting fraud, and permits other parties to interrupt the conversation through various means. The protocol's interpretation of silence (the absence of a challenge to a new state) as implicit permission is the heart of the problem. Indeed, an attacker might use DDoS attacks to create the appearance of silence.

Because a block may contain an improper state transition, the Fraud Proof protocol provides a time frame — the Dispute Time Delay (DTD) — for disputing this incorrect state. This window is divided into blocks. The L2 state transition is regarded as correct if no Fraud Proof is submitted within the DTD. If a Fraud Proof is sent to the smart contract and is judged to be correct (i.e., was submitted inside the DTD and really proves an improper state transition), the smart contract will, at the very least, commit to the previous correct L2 state. Additional procedures, such as imposing sanctions on the breaching party, may be taken.

The duration of the DTD is important since the longer it is, the more likely it is to identify an improper state transition, which is beneficial. However, the longer it is, the longer users must wait, for example, to withdraw funds, which is undesirable.

Validity Proofs

A validity proof, also known as a zero knowledge (ZK) proof, is a transaction verification technique that takes place between a prover, who creates a proof for certain information, and a verifier, who verifies the proof with no information shared between the two.

The information provided between a prover and a verifier is known as a witness, and it is often the solution to a complicated mathematical problem. In essence, the prover must demonstrate correct knowledge of the witness, and the verifier must be able to reliably determine if the prover has knowledge of the witness.

Validity Proofs show that a state transition is correct. They represent a more pessimistic view on the world. Values reflecting L2 state are included in blocks if and only if that state is accurate.

Here's a quick explanation:

A smart contract receives a representation of some off-chain computation
The smart contract only updates the blockchain with this new value when it has been validated as correct.

The major benefits of Validity Proofs are that the blockchain will always represent a true L2 state, and that a new state may be depended on and utilized instantly. The key downside is that proofs are required for every state transfer, not only those that are challenged, which require more computational power and have a negative influence on scalability.

51% Attacks

We would want to focus on 51%-attacks on L1 out of the many conceivable assaults. There has lately been an increase in these, including an attack on Ethereum Classic. How might such assaults affect Fraud Proofs and Validity Proofs?

51% Attacks on Fraud Proofs

A 51% attack allows an attacker to insert a fake state onto the blockchain and, for instance, take funds from an exchange that is being attacked. In more details:

The attackers build BlockFr through a forged state transition. For example, it may include a transfer of all the funds in the exchange to their wallet.
They will layer DTD blocks on top of BlockFr, culminating in a block that involves a withdrawal of the funds given in BlockFr.
The chain is then extended beyond the DTD and beyond the present chain by the attackers. They have the ability to do so since they control 51% of the hashrate.
Surprisingly, the operating cost of initiating such an assault is independent of the funds owned by the exchange under attack. This implies that as the level of activity on cryptocurrency exchanges rises, they become more appealing targets for such attacks.

Source: StarkWare

To conclude, the core issue is that an L2 solution establishes its own logic, allowing a block containing a fraudulent state transfer. The ledger’s status after attackers took the funds is a legal state, despite the fact that no duplicate spending happened, yet, a fraud happened.

51% Attacks on Validity Proofs

A 51%-attack can simply unwind recorded history and perhaps give an alternate history, and crucially, this alternate history is equally true. The variety of attacks available here is restricted to those available at L1. Unwinding of recorded history can be a hugely profitable move in crypto-to-crypto exchanges (especially when all assets traded reside on the same blockchain). A seller, for example, may be thrilled to unwind a transaction that occurred at what, in retrospect, was a rock-bottom price, but there is no way of outright stealing assets in an exchange of crypto-assets on a specific blockchain.

Final Words

Until recently, fraud proofs and optimistic rollups were preferred since ZK proofs were more difficult to produce and computationally intensive, but a number of new breakthroughs in the zero knowledge space are making ZK rollups more accessible than ever.

ZK rollups are a developing go-to layer-2 scaling option, with more zkEVMs on the increase and the promise of more secure, informationless, and non-interactive transactions.

About Orochi Network

Orochi Network is a cutting-edge zkOS (An operating system based on zero-knowledge proof) designed to tackle the challenges of computation limitation, data correctness, and data availability in the Web3 industry. With the well-rounded solutions for Web3 Applications, Orochi Network omits the current performance-related barriers and makes ways for more comprehensive dApps hence, becoming the backbone of Web3's infrastructure landscape.