-
Notifications
You must be signed in to change notification settings - Fork 1
Do not use go-ethereum for hasher. #159
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
base: main
Are you sure you want to change the base?
Conversation
b194d49 to
3e87205
Compare
protocol/hashing.go
Outdated
| h.Write(data) //nolint:revive // keccak256 never returns an error | ||
| var out [32]byte | ||
| copy(out[:], h.Sum(nil)) | ||
| h.Reset() |
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.
is this h.reset necessary? We already reset right before usage on line 24
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.
Good point. The pool is private, so there's no benefit to the extra caution.
|
|
CI failing, but will approve after |
| var hasherPool = sync.Pool{ | ||
| New: func() any { | ||
| return sha3.NewLegacyKeccak256() | ||
| }, | ||
| } |
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.
Why is this needed?
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.
It lets you reuse the keccak objects instead of reallocating them every time. I'll add a benchmark, now I'm curious how impactful it is.
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.
Looks like object pooling improves things from 378ns -> 251.2ns. I tested with different inputs, and it seems to be a fixed ~100ns overhead for object allocation with the total duration going up based on the input data size.
goos: linux
goarch: amd64
pkg: github.com/smartcontractkit/chainlink-ccv/protocol
cpu: 13th Gen Intel(R) Core(TM) i9-13900HX
BenchmarkHashing
BenchmarkHashing-32 4575128 251.2 ns/op
BenchmarkHashinbBaseline
BenchmarkHashinbBaseline-32 2765898 378.0 ns/op
PASS
fdffd2c to
085ba4d
Compare
E2E Smoke Test Results
Full logs are available in the workflow artifacts. |
|
Code coverage report:
|
The go-ethereum hash function we need is a trivial wrapper around standard go libraries. Use them directly rather than calling into go-ethereum.