Skip to content

feat: Simplify op-deployer scripts: Add runtime ABI validation [2/N] #15111

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

Merged
merged 7 commits into from
Apr 1, 2025

Conversation

janjakubnanista
Copy link
Contributor

@janjakubnanista janjakubnanista commented Mar 28, 2025

Description

ABI runtime validation utilities to be used when loading deploy scripts:

  • matchTypes ensures that a given ABI type matches a Go type
  • matchArguments ensures that a list of ABI arguments (function params or return values) matches Go types

These validators will be executed when a script ABI is loaded in runtime and will halt any execution if the Go types do not match the loaded ABI.

Unfortunately, this kind of validation is not provided out of the box by go-ethereum.

Considered alternatives

A notable alternative is to use Pack and Unpack methods to validate the ABI <-> Go type mapping. Unfortunately, this means that besides the struct types, the consumer of this code would need to provide two additional values per every ABI method to be validated - an example input and an example output.

Besides the additional code required, the validation would only be correct if all the example fields provided had different values. This is due to a quirk of the ABI decoding - the fields will be decoded in the order of definition and their names might not match. As an example:

// With a go struct defined like this
type MyStruct struct {
  FieldB common.Address // Notice this field being defined first
  FieldA common.Address
}
struct MyStruct {
  address fieldA;
  address fieldB;
}

Using these two as an example, the ABI decoder would place the solidity value of fieldA into FieldB of the go struct. If this was not the case (which it might not be after we pull upstream), we could simplify this validation code to minimum since this peculiarity is the only reason this code has been introduced.

Relates to #14976

Copy link

codecov bot commented Mar 28, 2025

Codecov Report

Attention: Patch coverage is 98.80952% with 1 line in your changes missing coverage. Please review.

Project coverage is 42.30%. Comparing base (df1d18a) to head (6f14a10).
Report is 1 commits behind head on develop.

Files with missing lines Patch % Lines
op-chain-ops/script/abi.go 98.80% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop   #15111      +/-   ##
===========================================
- Coverage    46.31%   42.30%   -4.01%     
===========================================
  Files         1209     1038     -171     
  Lines       102317    92144   -10173     
===========================================
- Hits         47383    38986    -8397     
+ Misses       51566    49968    -1598     
+ Partials      3368     3190     -178     
Flag Coverage Δ
cannon-go-tests-32 ?
cannon-go-tests-64 ?
contracts-bedrock-tests ?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
op-chain-ops/script/abi.go 98.80% <98.80%> (ø)

... and 181 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@janjakubnanista janjakubnanista marked this pull request as ready for review March 31, 2025 02:50
@janjakubnanista janjakubnanista requested review from a team as code owners March 31, 2025 02:50
@janjakubnanista janjakubnanista requested a review from a team as a code owner March 31, 2025 21:01
@janjakubnanista janjakubnanista force-pushed the jan/op-deployer--002 branch 3 times, most recently from e5502ed to 34514c6 Compare March 31, 2025 21:11
Base automatically changed from jan/op-deployer--001 to develop April 1, 2025 15:38
@janjakubnanista janjakubnanista self-assigned this Apr 1, 2025
@janjakubnanista janjakubnanista added this pull request to the merge queue Apr 1, 2025
Merged via the queue into develop with commit 7266b11 Apr 1, 2025
50 checks passed
@janjakubnanista janjakubnanista deleted the jan/op-deployer--002 branch April 1, 2025 19:25
}

// We check for arrays first (i.e. fixed length slices like uint256[2])
if abiType.T == abi.ArrayTy {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could reduce a few lines of code if you use a switch abiType.T statement or if/else instead of several independent if blocks.

if test.err == "" {
require.NoError(t, err)
} else {
require.EqualError(t, err, test.err)
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you use require.ErrorIs to compare to custom error instance instead of require.EqualError? Would be less brittle than the current string matching approach

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay I'll change, I used EqualError since the errors are wrapped using fmt.Errorf and the other assertions kept failing on the wrapping part - since I am mostly interested in the message I went with the string approach

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants