-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP: Emit log on revert #9390
base: master
Are you sure you want to change the base?
Conversation
File
|
The commit d509968 (as a parent of 5609fb5) contains errors. |
|
||
## 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
## Rationale | ||
|
||
This is the simples possible implementation that allows revert messages to be accessible via RPC. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your sentence introduces the idea well, but it could be strengthened by providing more justification. If the goal is to explain why revert messages should be accessible via RPC, consider expanding on why this implementation is preferable. For example, highlighting its efficiency, ease of integration, or benefits for developers would make the rationale more compelling.
## Rationale | |
This is the simples possible implementation that allows revert messages to be accessible via RPC. | |
## Rationale | |
This is the simplest possible implementation that allows revert messages to be accessible via RPC. |
This PR proposes to emit a log containing the revert message for reverted transactions, making it accessible via standard RPC without the need for tracing.