-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
50 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
--- | ||
eip: xxxx | ||
title: Emit log on revert | ||
description: Top level reverts emit a log with revert message | ||
author: Shoham Chakraborty (@shohamc1), Alex Forshtat (@forshtat) | ||
discussions-to: https://ethereum-magicians.org/t/eip-xxxx-emit-log-on-revert/22918 | ||
status: Draft | ||
type: Standards Track | ||
category: Core | ||
created: 2025-02-20 | ||
--- | ||
|
||
## 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`: `TBD` | ||
* `DATA_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](../LICENSE.md). |