[Feature]: Integrate GPG Wallet signing with Modular Account Framework

[sumitvekariya]

Overview

This feature request proposes integrating GPG signature signing/verification capabilities from the gpg-wallet project with the Modular Account framework. This integration would allow users to sign and verify transactions using GPG keys, providing enhanced security and flexibility for account owners.

Background

Currently, Modular Account supports validation modules such as SingleSigner validation (EOAs) and WebAuthn validation (passkeys). However, there is no support for GPG keys, which are widely used in cryptographic applications and offer strong security properties.

The gpg-wallet repository has built a complete implementation of a GPG-based wallet that leverages a custom precompile at address 0x696 to verify GPG signatures efficiently. By integrating this capability into Modular Account, we can offer users additional authentication options and enhance security.

Detailed Proposal

1. Create a new GPG Validation Module:

   • Develop a new validation module that can verify GPG signatures
   • Utilize the precompile from gpg-wallet at address 0x696 for efficient verification
   • Support the same signature verification patterns as used in gpg-wallet

2. Implement GPG Key Management:

   • Design storage for GPG public keys and key IDs within the validation module
   • Support key registration, rotation, and revocation
   • Allow multiple GPG keys for a single account

3. Create a GPG Verifier Library:

   • Abstract the GPG signature verification logic into a reusable library
   • Support the same interface as used in gpg-wallet
   • Ensure gas efficiency in verification operations

4. Account Factory Integration:

   • Add deployment options to create a Modular Account with GPG validation pre-installed
   • Support embedding of GPG key information during account creation

5. ERC-4337 Integration:

   • Implement UserOp validation for GPG signatures
   • Ensure bundlers can properly process GPG-signed operations

6. Documentation and Examples:

   • Create comprehensive documentation for users wanting to use GPG with their Modular Account
   • Provide examples of how to generate appropriate signatures from GPG keys
   • Document the security benefits and trade-offs

Benefits

• Enhanced security through GPG's robust cryptographic infrastructure
• Support for hardware security keys that use GPG
• Ability to leverage existing GPG infrastructure for identity and key management
• Broader authentication options for account owners
• Compatibility with existing tooling in the GPG ecosystem

Technical Considerations

• The GPG precompile (at address 0x696) needs to be supported by the chain
• Need to ensure proper handling of gas costs for GPG signature verification
• Key management must be secure and user-friendly
• Standard testing approaches may need to be extended to verify GPG signature validation

Implementation Path

1. Create a new GPG verification library based on gpg-wallet's implementation
2. Develop a GPG validation module that conforms to ERC-6900 standards
3. Implement integration with the account factory
4. Add comprehensive tests for all GPG validation scenarios
5. Optimize for gas efficiency
6. Document the new functionality thoroughly

Resources

• GPG Wallet Implementation
• ERC-6900: Modular Account Standards
• ERC-4337: Account Abstraction

[adamegyed]

Hi @sumitvekariya, this would be a great new module to create! Happy to help support you with this project.

For implementing the module, you could base most of it on the design of SingleSignerValidationModule, which uses Ethereum private keys (secp256k1) for ownership management, and adapt it to GPG key validation.

Instead of using OpenZeppelin's ECDSA library (which uses the ecrecover precompile under-the-hood), you could replace this step with a call to the GPG precompile via a library. Runtime validation could either be implemented as a custom EIP-712 struct for authorizing calls outside of the EntryPoint, or support for this type of validation could be omitted. And as a stub contract for the module, you could use ModuleBase.sol.

Note that if the public key is bigger that 32 bytes, you should use a struct like PubKey in WebAuthnValidationModule.sol to store it per-user, per-id. It should use fixed-size solidity data types, because using a storage variable of type bytes in this mapping would cause the data to be held in "non-address-associated storage" by the 4337 definition, which could cause issues with bundlers or with gas estimation. (details here: https://eips.ethereum.org/EIPS/eip-7562#storage-rules)

Please let us know if you have any questions, or run into issues in this process.

Testing

Foundry has added a few different way to test with custom precompiles:

• They have a guide for using vm.etch(...) to test custom precompile code via mocked solidity: https://book.getfoundry.sh/cheatcodes/etch#using-vmetch-for-enabling-custom-precompiles
• There is also a way to inject custom precompiles into anvil, and run a forking node or a fresh dev environment: Feature: Custom Precompiles for Anvil  foundry-rs/foundry#1505