Refactor EVM operations to use unified Signer abstraction #180
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- introduce evm.Signer interface with AvalancheGo, no-op, and null implementations - replace private key fields/params with signer instances across blockchain, contract, and validator manager flows - update EVM client helpers and contract utilities to sign transactions via signer - adapt PoS/PoA initialization, precompile helpers, and interchain deployer to signer-based workflow - refresh EVM tests and add key path fixtures to cover the new signing model
Refactor the EVM signer architecture from an interface-based pattern to a concrete struct pattern for better type safety and nil-safety: - Replace Signer interface with concrete *Signer struct - Consolidate AvalancheGoSigner, NoOpSigner, and NullSigner into single type - Add NewCryptoSigner() for real cryptographic signing via keychain - Add NewNoOpSigner() for generating unsigned transactions - Implement nil-safe methods (IsNoOp, SignTx, Address, TransactOpts) - Use nil checking instead of type assertions for NoOp detection - Update all function signatures across codebase to use *Signer - Add unit tests for signer
- Add NewSignerFromPrivateKey() convenience constructor that creates a signer directly from a private key string, eliminating the need to manually create a SoftKey and extract the keychain - Rename NewCryptoSigner() to NewSigner() for cleaner API - the "Crypto" qualifier is redundant since actual signing is the default expectation, with NewNoOpSigner() being the explicitly-named special case - Add comprehensive unit tests for NewSignerFromPrivateKey covering success and error cases - Update all existing test references from NewCryptoSigner to NewSigner
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why this should be merged
This PR consolidates EVM signing functionality from multiple patterns (raw private key strings, keychains, address-based operations) into a single unified Signer struct. This refactoring:
How this works
The PR introduces a new evm.Signer struct that wraps Avalanche's keychain.Signer interface, enabling support for various signing backends (private keys, Ledger hardware wallets, remote signers, etc.).
Three constructors are provided:
The Signer provides:
It is nil safe (no panics)
All EVM client methods have been refactored to accept *Signer instead of private key strings.
How this was tested