Abstract
All calls to the REVERT opcode with non-zero size must emit a log with revert data, making it accessible via standard RPC without the need for tracing.
Motivation
Revert messages are currently inaccessible to users as they are not available via standard RPC. Instead, users have to request a node to trace the transaction and check the stack and memory at the moment when the REVERT opcode was executed.
This introduces overhead for users and nodes - users must make an additional request to find out why their transaction failed, and the node has to replay the full transaction (which may be slow and computationally expensive) to get back a relatively small piece of data.
Currently it is up to smart wallet developers to emit logs before a revert, however this is not a standard feature and thus cannot be relied upon by tools such as client libraries and block explorers. Making this log part of the protocol allows these tools to rely on logs for revert reasons.
Specification
Parameters
REVERTTOPIC:TBDDATA_LIMIT:TBD
Functionality
Whenever REVERT is called with non-zero size, emit a log identical to a LOG1 with the topic REVERTTOPIC. The log data is the raw bytes of the revert message. The data is truncated to DATA_LIMIT.
Rationale
This is the simplest possible implementation that allows revert messages to be accessible via RPC methods. It does not require any changes to client libraries, or other RPC consumers as it is backward compatible. It does not introduce new RPC methods or new opcodes.
Backwards Compatibility
Reverted transactions may now contain up to one log.
Security Considerations
Reverted transactions must cost at least intrinsic gas (21000 gas), which is much more expensive than the LOG1 opcode (750 gas). Hence, this EIP does not introduce any new avenues to inflate Ethereum storage requirements. However, it is expected to increase the average number of logs.
Copyright
Copyright and related rights waived via CC0.