Pluggable Signature Schemes

[0xhssn]

Hey Ethers team! 👋

I'd like to propose adding support for pluggable signature schemes to make Ethers.js more flexible for the evolving blockchain landscape. This enhancement would allow the library to handle cryptographic signature algorithms beyond ECDSA (like BLS and Schnorr) while maintaining backward compatibility.

Why This Matters Now

The Ethereum ecosystem is rapidly diversifying beyond the original ECDSA signature scheme:

• ZK-rollups and L2s are increasingly adopting BLS signatures for aggregation properties
• Privacy-focused applications need Schnorr signatures for their multi-signature capabilities
• Cross-chain applications require flexibility to work with different signature schemes
• Enterprise adopters often have specific regulatory requirements around signature algorithms

Many teams are currently maintaining forks or complex workarounds to handle these needs, creating unnecessary fragmentation. A pluggable architecture would allow Ethers.js to remain the universal standard across these emerging use cases without sacrificing its clean API or security model.

In short: as signature diversity in the ecosystem grows, Ethers.js risks being sidelined for innovative projects unless it can accommodate multiple signature schemes elegantly.

Proposed Architecture

I suggest implementing a modular SignatureProvider interface that would be integrated into the Signer class:

1. Create an abstract SignatureProvider interface
2. Refactor existing ECDSA implementation to conform to this interface
3. Modify the Signer class to use the provider pattern for signature operations
4. Default to ECDSA for full backward compatibility

Usage Example

Here's a simplified example of how a custom scheme might work:

import { Wallet, SignatureProvider } from "ethers";

// Implementing a BLS signature provider
class BLSSignatureProvider implements SignatureProvider {
  constructor(private readonly privateKey: Uint8Array) {}
  
  async signDigest(digest: Uint8Array): Promise<SignatureResponse> {
    // BLS signature implementation
    return {
      scheme: "BLS",
      signature: signatureBytes,
      compressedSignature: "0x..."
    };
  }
  
  // Other required methods: recoverPublicKey, computeAddress, etc.
}

// Using it with a wallet
async function demo() {
  const blsProvider = new BLSSignatureProvider(privateKey);
  const wallet = new Wallet({ signatureProvider: blsProvider });
  
  // Works with existing methods
  const signedTx = await wallet.signTransaction(transaction);
  const signature = await wallet.signMessage("Hello Ethereum!");
}

Benefits

This approach offers several advantages:

1. Zero breaking changes - All existing code continues to work as-is
2. Futureproofing - Ethers.js can quickly adapt to new signature schemes
3. Unified ecosystem - Reduces the need for forks and custom implementations
4. Developer flexibility - Projects can implement exactly what they need

Implementation Plan

If there's interest, I'd be happy to submit a PR with:

• Interface definitions
• Refactored Signer class
• ECDSA implementation using the new interface
• Basic tests
• Sample alternative implementation (BLS)

What do you think? Would this be a valuable addition to Ethers.js?