From d509968014d295e4745ce6e04b856c06486a6aef Mon Sep 17 00:00:00 2001 From: Shoham Chakraborty Date: Thu, 20 Feb 2025 12:29:50 +0800 Subject: [PATCH 1/4] Add new EIP --- EIPS/eip-xxxx.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 EIPS/eip-xxxx.md diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-xxxx.md new file mode 100644 index 00000000000000..a973e0f280792f --- /dev/null +++ b/EIPS/eip-xxxx.md @@ -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 are 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 - the user 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 simples possible implementation that allows revert messages to be accessible via RPC. + +## Backwards Compatibility + +Reverted transactions may now contain up to one log. + +## Security Considerations + +Reverted transactions must cost atleast intrinsic gas which is atleast 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). From aede0ec7f5e9458d2f46449baba2b5ec96d44d1c Mon Sep 17 00:00:00 2001 From: Shoham Chakraborty Date: Sat, 22 Feb 2025 13:00:02 +0800 Subject: [PATCH 2/4] Spelling and grammar --- EIPS/eip-xxxx.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-xxxx.md index a973e0f280792f..eafe91ee9852a3 100644 --- a/EIPS/eip-xxxx.md +++ b/EIPS/eip-xxxx.md @@ -16,9 +16,9 @@ All calls to the REVERT opcode with non-zero size must emit a log with revert da ## Motivation -Revert messages are currently are 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. +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 - the user 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. +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. @@ -35,7 +35,7 @@ Whenever `REVERT` is called with non-zero size, emit a log identical to a LOG1 w ## Rationale -This is the simples possible implementation that allows revert messages to be accessible via RPC. +This is the simplest possible implementation that allows revert messages to be accessible via RPC. ## Backwards Compatibility From 9576cf4e06f2adefdd90f06a8137a92d9521825c Mon Sep 17 00:00:00 2001 From: Shoham Chakraborty Date: Tue, 25 Feb 2025 10:07:52 +0800 Subject: [PATCH 3/4] Update EIP --- EIPS/eip-xxxx.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-xxxx.md index eafe91ee9852a3..febd8ccc4786d3 100644 --- a/EIPS/eip-xxxx.md +++ b/EIPS/eip-xxxx.md @@ -43,7 +43,7 @@ Reverted transactions may now contain up to one log. ## Security Considerations -Reverted transactions must cost atleast intrinsic gas which is atleast 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. +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 From f011351663ab33ca214fd6d9b0ba619bdcc439ac Mon Sep 17 00:00:00 2001 From: Shoham Chakraborty Date: Tue, 25 Feb 2025 10:44:59 +0800 Subject: [PATCH 4/4] Expound rationale --- EIPS/eip-xxxx.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-xxxx.md index febd8ccc4786d3..fe2bff6203361b 100644 --- a/EIPS/eip-xxxx.md +++ b/EIPS/eip-xxxx.md @@ -35,7 +35,7 @@ Whenever `REVERT` is called with non-zero size, emit a log identical to a LOG1 w ## Rationale -This is the simplest possible implementation that allows revert messages to be accessible via RPC. +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