Skip to content
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

minor/cosmetic improvements to data gas handling in state transition #83

Merged
merged 1 commit into from
Dec 17, 2022

Conversation

roberto-bayardo
Copy link
Collaborator

@roberto-bayardo roberto-bayardo commented Dec 16, 2022

  • fix error that wasn't wrapping one of the underlying execution errors as expected by the error handler

  • change dataGasUsed to return type uint64 which is more convenient than big int

  • remove confusing comment I had added earlier around gas refunds

@roberto-bayardo roberto-bayardo marked this pull request as ready for review December 16, 2022 23:57
@roberto-bayardo
Copy link
Collaborator Author

just some minor issues I spotted while porting this code to erigon. Nothing that should affect your testing as it's mostly cosmetic.

if st.evm.Context.ExcessDataGas == nil {
return fmt.Errorf("sharding is active but ExcessDataGas is nil. Time: %v", st.evm.Context.Time.Uint64())
return fmt.Errorf("%w: sharding is active but ExcessDataGas is nil. Time: %v", ErrInsufficientFunds, st.evm.Context.Time.Uint64())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more of an "internal error" rather than an ErrInsufficientFunds. I think the previous error was fine as-is.

Copy link
Collaborator Author

@roberto-bayardo roberto-bayardo Dec 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my thinking when I first wrote the code, but as I looked at the other error handling it appears if you don't wrap some error then executionResult.Failed() will return false, which struck me as potentially problematic. Perhaps we should create an "ErrInternalFailure" type to wrap for these oddball & unexpected failures?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to use a new "ErrInternalFailure" for this.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using an ErrInternalFailure is fine. Though I don't see how this affects the ExecutionResult, which only yields errors as bytecode execution faults.

@roberto-bayardo roberto-bayardo merged commit a915d56 into eip-4844 Dec 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants