Fraud Proofs

Within Bitcoin

• Originally envisioned by Satoshi Nakamoto, fraud proofs could significantly improve the security of SPV-nodes (or: “light wallets”); Bitcoin nodes that do not verify all transactions on the network or store the complete blockchain.
• To check whether a transaction has taken place, SPV-nodes merely scan the blockchain for the relevant transaction ID. If they find it, that means a miner included the transaction in a block. But SPV-nodes do not validate whether the transaction adhered to Bitcoin’s consensus rules. As such, SPV-nodes trust miners to play fair, rather than verify they do. In a worst case scenario, this could even mean that miners pay SPV-nodes with bitcoin created out of nothing, for instance by creating transactions with no inputs, or by awarding themselves excess fees in the coinbase transaction.
• These types of problems could be solved by requiring miners to include extra data in the Segregated Witness Merkle Tree, specifying where the bitcoin locked up in all transactions came from, exactly. That way, if a block contains invalid transactions, a short and easy-to-check fraud proof can be constructed by any full node. This full node can send the fraud proof to SPV-nodes, so they know to reject the block.
• That said, even with fraud proofs, SPV-nodes would not quite offer the same level of security as full nodes. Most importantly, the fraud proof solution requires that SPV-nodes can communicate with the network free from censorship. (For instance: censorship from government-sanctioned ISPs.) Additionally, SPV-nodes need at least one full node on the network to actually produce the fraud proofs.

Within ETH 2.0

• From the blog of Vitalik (7-4-2021):

"Fraud proofs are a system where to accept the result of a computation, you require someone with a staked deposit to sign a message of the form "I certify that if you make computation C with input X, you get output Y". You trust these messages by default, but you leave open the opportunity for someone else with a staked deposit to make a challenge (a signed message saying "I disagree, the output is Z"). Only when there is a challenge, all nodes run the computation. Whichever of the two parties was wrong loses their deposit, and all computations that depend on the result of that computation are recomputed."