The issue of revert

[ChihChengLiang]

What's wrong

The evm has the REVERT opcode to mark the tx as failing but also charge the gas for the computation that already happened to prevent dos.

It seems no need to implement REVERT in the zkevm, since the proof only is only presented on l1 when the computation completes successfully.

But there are many applications depends on revert. (TODO: add examples)

[vbuterin]

The reason why we need to handle reverts is that reverts can happen not just at whole-transaction-level but also inside subcalls. There are important usecases where you need to make subcalls that have the possibility of reverting, and where the transaction can still go through if the subcall reverts. Some examples include:

• Sponsored transactions (sponsor still needs to be paid if the sponsored op fails)
• Optimism fraud proofs (their fraud proof involves executing near-arbitrary [but quasi-purity-checked] EVM code on-chain, and verifying the results of execution even if they include failed calls)
• Higher-layer account abstraction (see https://notes.ethereum.org/@vbuterin/alt_abstraction; the tx needs to go through even if internal ops fail)

[ChihChengLiang]

Thanks for the examples! I assume the sponsor transactions are the one defined here https://eips.ethereum.org/EIPS/eip-2711#sponsored-transactions?

[vbuterin]

The general category of sponsored transactions; that's one implementation, there's also a possible implementation in the context of abstraction through user ops.

[ChihChengLiang]

Updates on this: We allow the prover to prover all possible revert cases. Behaviors of reverting in subcalls are addressed in later EVM circuit specs like #52