-
Notifications
You must be signed in to change notification settings - Fork 9
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
Feat: Refactore Executor #64
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -103,7 +103,7 @@ pub trait Handler { | |
value: U256, | ||
init_code: Vec<u8>, | ||
target_gas: Option<u64>, | ||
) -> Capture<(ExitReason, Option<H160>, Vec<u8>), Self::CreateInterrupt>; | ||
) -> Capture<(ExitReason, Vec<u8>), Self::CreateInterrupt>; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is technically a breaking change from the perspective of sputnikvm as a library since we are changing the signature of a method on a public trait. This is not an issue, especially if we are not planning on ever syncing up with upstream again and we are the only users of the library. But I thought it is worth pointing out just in case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it's breaking changes. With the release of |
||
/// Feed in create feedback. | ||
/// | ||
/// # Errors | ||
|
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.
I don't think we can remove the address return here because
finish_create
pushes the address onto the EVM stack which I think is required for theCREATE
instruction.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.
No, we can.
handler.create
operates overcreate_inner
and doesn't return either. In terms of internal refactoring, it's good enough to remove redundant code. There's no case for that logic, and it was added "because I can" without design rethinking. It's good practice to follow Keep It Simple (KIS), simplifying things for better productivity and clear algorithms and code.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.
Ah, I see. The
Capture::Exit
case used to always haveaddress: None
because it was only returned when the call tocreate_inner
encountered an error and therefore no contract was created. The happy path is returningCapture::Trap
andfinish_create
ends up being called later with the created address as part of the EVM call stack handling logic. Maybe it is worth adding a comment that theCapture::Exit
case only happens if there was an error. Maybe also worth addingdebug_assert!(!reason.is_succeed())
to make sure this assumption is upheld in the future.As for removing unused code, I fully agree with doing that to make maintaining the code easier going forward! I just wanted to make sure the code path really was unused.
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.
I agree, thanks.
In order to get closer to proving correctness, I implemented 100% passing of tests from ethereum/tests and ethereum/execution-spec-tests. And this is a big step forward. For greater persuasiveness, it is necessary to cover the entire code with tests. However, this task will take, in my opinion, a lot of time, since the EVM logic is really complex. This does not mean that it should not be done - it is just a lower priority.