[SDK] Question on the Design Choice of Signer Class in zkSync's ether SDK for MetaMask Integration

[nooma-42]

Environment

Testnet

Acknowledgement

• I understand that issues are expected with the Go SDK as they are being updated.

Issue Description

The comment wrote a sample usage saying that this is for metamask injection. However, this signer inherits from jsonRpcSigner.

1. Why not wrap abstract class signer or wallet from vanilla ethers? given metamask injection mentioned above.
2. Is this comment conflict with the implementation?

// This class is to be used on the frontend, with metamask injection.
// It only contains L2 operations. For L1 operations, see L1Signer.
// Sample usage:
// const provider = new zkweb3.Web3Provider(window.ethereum);
// const signer = provider.getSigner();
// const tx = await signer.sendTransaction({ ... });
export class Signer extends AdapterL2(ethers.providers.JsonRpcSigner) {

ref: https://github.com/zksync-sdk/zksync-ethers/blob/754e723e9ff1f63eb46e31171824e39210779652/src/signer.ts#L96

Expected Behavior

wrap abstract class signer or wallet from vanilla ethers

Code Example

// This class is to be used on the frontend, with metamask injection.
// It only contains L2 operations. For L1 operations, see L1Signer.
// Sample usage:
// const provider = new zkweb3.Web3Provider(window.ethereum);
// const signer = provider.getSigner();
// const tx = await signer.sendTransaction({ ... });
export class Signer extends AdapterL2(ethers.providers.JsonRpcSigner) {

ref: https://github.com/zksync-sdk/zksync-ethers/blob/754e723e9ff1f63eb46e31171824e39210779652/src/signer.ts#L96

Repo Link (Optional)

https://github.com/zksync-sdk/zksync-ethers/blob/754e723e9ff1f63eb46e31171824e39210779652/src/signer.ts#L96

[danijelTxFusion]

Is this comment conflict with the implementation?

The code that you are posting refers to zksync-ethers based on the ethers-v5 implementation. The links that you posted refer to the ethers-v6 implementation. Just to make it clear, the ethers-v5 implementation is available on the zksync-ethers repository's ethers-v5 branch, while the ethers-v6 implementation is available on the main branch.

Why not wrap abstract class signer or wallet from vanilla ethers? given metamask injection mentioned above.

In ethers-v5, ethers.provider.Web3Provider returns JsonRpcProvider from the getSigner() method (Web3Provider extends JsonRpcProvider). The same applies to ethers-v6 with ethers.BrowserProvider. Therefore, the Signer extends the JsonRpcProvider to align with the design of ethers. This is why neither ethers.Wallet nor ethers.Signer are used. Also, ethers.Signer does not work with adapters. AdapterL2 and AdapterL1 cannot function with abstract classes as they require a constructor from a concrete class.