-
Notifications
You must be signed in to change notification settings - Fork 4
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
Efficient Fiat-Shamir challenges using hashing #15
Conversation
By avoiding ssz merklelization, we significantly reduce the latency of generating FS challenges. Before: ``` BenchmarkVerifyMultiple/8-6 16 69890960 ns/op 25221325 B/op 399904 allocs/op BenchmarkVerifyMultiple/16-6 8 138506286 ns/op 50439658 B/op 799792 allocs/op ``` After: ``` BenchmarkVerifyMultiple/8-6 27 41349482 ns/op 22059083 B/op 301451 allocs/op BenchmarkVerifyMultiple/16-6 14 80868200 ns/op 44114668 B/op 602909 allocs/op ```
This is great! I assume this is not a backwards compatible change since the hash values presumably change? |
yup. This isnt backwards compatible |
OK, will try to implement in prysm soon then. |
|
||
// sszHash returns the hash ot the raw serialized ssz-container (i.e. without merkelization) | ||
func sszHash(c codec.Serializable) ([32]byte, error) { | ||
sha := sha256.New() |
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 sha256 and not keccak/sha3? I guess it might be faster but possibly less future proof?
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 real reason other than to be consistent with how hashing is already done on the beacon chain. sha256 is the only hash being used on the beacon chain.
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.
Thanks, implementation consistency is certainly a good reason.
Will merge once the spec has been updated for sha256 challenges. |
By avoiding ssz merklelization, we significantly reduce the latency of generating FS
challenges.