Fraud Proofs

Mantle v2 Tectonic has been released, please move to the new documentation!

Optimistic Rollups assume state transition validity for all Layer-2 (L2) transactions, unless proven otherwise. Hence, they’re also called assertions, since their validity hasn’t been established per se. The verification logic takes evidence of an invalid state transition to initiate the validation process, and fraud proofs are the medium to provide that. The protocol allows for a dispute window during which a network actor can come forward and submit a fraud proof disputing a state they deem to be incorrect. This challenge period is roughly 7 days for most optimistic rollup protocols. Any transaction that isn’t disputed within this time frame is assumed to be valid by default.

Types of Fraud Proofs

Fraud proofs can be classified into two distinct categories: non-interactive and interactive. Let's go over the differences in these two types of proving mechanisms.

Non-interactive Fraud Proofs

Non-interactive fraud proofs use a method where no other parties are needed to prove the incorrectness of an assertion. They basically run all the state transitions between two assertions to establish whether the resultant state is consistent or not. They are simpler to design and implement, but they place limitations on the size of assertions, since the assertions need to be small enough to run with the computational capabilities of the current EVM (Ethereum Virtual Machine) architecture.

Interactive Fraud Proofs

Interactive fraud proofs, on the other hand, involve two or more parties that work in tandem to verify an assertion, i.e., a party claiming a fraudulent assertion, and a party defending the said assertion. The verifier narrows down the assertion to a single state transition by interacting with the challenger, and eventually only verifies that one transition to establish its validity. This back and forth introduces a new level of complexity in the protocol, and can be harder to design safely. But it has the advantage of not placing any limitations on L1, due to a much smaller volume of actual on-chain execution.

Improved Fraud Proofs on Mantle Network

For Mainnet Alpha, fraud proofs are currently not enabled and are currently in development. Refer to our Testnet or Github for the latest progress.

In the currently popular model for fraud proofs, the contract that settles disputes — the on-chain verifier — can only execute instructions in a lower-level virtual machine such as MIPS or WASM. This forces an Ethereum Virtual Machine (EVM) client to re-compile their fraud proof into the lower-level language to be interpretable to the on-chain verifier. This means that the content of a fraud proof is generated outside the scope of the EVM.

The implication here is that because of the low-level transpiling, there is no way to guarantee that a fraud proof's contents are derived directly from a compliant EVM client. In other words, the on-chain verifier is blind to the producer of the fraud proof! This blind spot interferes with the trust-minimization that is imbued into the Ethereum client to begin with. It would be far better for a fraud proof to be evaluated using EVM instructions directly.

This is precisely the sort of system that Mantle network implements. Mantle network establishes transaction validity using the interactive fraud proof mechanism, and by compiling and verifying fraud proofs with EVM-level instructions we register a number of benefits:

1. Allow all Ethereum clients to interact with a common proof system, permissionlessly.

2. Reduce trust assumptions across verifiers, clients, and compilers.

The particular fraud proof model that is employed by Mantle network (testnet) is akin to the one deployed by Specular Network. You can learn more about it here.