Provide newtype wrappers for ed25519-consensus types
#1079
Labels
Comments
This was referenced May 20, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
May 27, 2024
## Summary The `ed25519-consensus` types not already wrapped in newtypes are wrapped in this PR. ## Background This is partly for consistency (we recently provided a newtype for the signing key), partly to avoid having third party types in our core crate's public API, and partly to support memoizing the address of the verification key. ## Changes - Provided newtypes in the `crypto` module of `astria-core` for `VerificationKey`, `Signature` and `Error`. - Replaced all usages of the naked `ed25519-consensus` types with the newtypes. - Replaced `Address::from_verification_key` with `VerificationKey::address`. ## Testing Provided unit tests for the `VerificationKey` to ensure the `PartialEq`, `Eq`, `PartialOrd`, `Ord` and `Hash` impls are correct given that they're hand-rolled in order to exclude the memoized address field. ## Related Issues Closes #1079.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of #1074 (specifically, 3515ac0), we put the
ed25519_consensus::SigningKeybehind a newtype wrapper, mainly to avoid having itsDebugimpl exposed.We want to wrap all the types from
ed25519-consensuswhich we consume in a similar way, partly for consistency, but mainly since it's good practice to not include dependencies' types in a crate's public API.The text was updated successfully, but these errors were encountered: