Skip to content

Conversation

@tcoratger
Copy link
Contributor

@tcoratger tcoratger commented Nov 23, 2025

Related #11

Copy link
Contributor

@b-wagn b-wagn left a comment

Choose a reason for hiding this comment

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

Thanks LGTM!

Only minor criticism I have is that we now use fields in the generalized XMSS file, which breaks a bit our abstractions. I wonder if it makes sense to require that encode and decode are defined for the parameter and hash type of the tweakable hash and then call those black-box here. Then move the encoding of field vectors into the tweakable hash file.

Not sure, just an idea.

@tcoratger
Copy link
Contributor Author

Thanks LGTM!

Only minor criticism I have is that we now use fields in the generalized XMSS file, which breaks a bit our abstractions. I wonder if it makes sense to require that encode and decode are defined for the parameter and hash type of the tweakable hash and then call those black-box here. Then move the encoding of field vectors into the tweakable hash file.

Not sure, just an idea.

Okay, so I tried to fix this with the best possible abstraction using a FieldArray abstraction. We have the same one in Plonky3 here: https://github.com/Plonky3/Plonky3/blob/b1f8c020c3120d6076339aacaffc414bf23533a4/field/src/array.rs#L11 but we can't use it because, due to the orphan rule, we can't implement a trait on it outside of the Plonky3 repository. This would have forced us to create a wrapper around it, which is even worse.

With this new abstraction, it should be super easy to build other SSZ implementations in follow-up pull requests for secret key and signature objects.

@tcoratger tcoratger merged commit a35156c into leanEthereum:main Nov 25, 2025
2 checks passed
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