[SDK] Allow overriding estimateGas Transaction signature

[hbriese]

Environment

Testnet

Acknowledgement

• I understand that issues are expected with the Python and Java SDK as they are being updated.

Issue Description

The JS Provider.estimateGas function always estimates a transaction's gas with a 65 byte signature (assumably for EOAs), and disregards any customData.customSignature

Expected Behavior

customData.customSignature is respected for estimateGas calls

Code Example

provider.estimateGas({
      ...
      type: EIP712_TX_TYPE,
      customData: {
        customSignature: '0x...'
      },
    }),

Repo Link (Optional)

No response

[dutterbutter]

Hmm, that's interesting 🤔. Thanks for pointing it out! I'll need some time to investigate this behaviour🕵️‍♂️. I'll post back here with any insights as to why that might be or if we should estimateGas accordingly. Thank you for the post 💯

[MexicanAce]

Hi @hbriese 👋 !

The way that zkSync Era estimates gas is via a Binary Search algorithm that modifies the gas_limit of the Transaction (See here for code).

Because of this, the signature will never match as expected, and this also leads to things like needing to update the nonce of the transaction while it runs inside of a Sandbox. As you can see in the underlying contract, the signature is never fully verified as the underlying data (e.g. gas_limit) has been modified.

[hbriese]

@MexicanAce thanks for your answer.
The problem arrises when additional data is passed in via the signature - not just a single ecdsa secpk1 signature.
In my case this additional data causes extra verification to be performed, thereby affecting the gas usage.

The expected behaviour is for the customSignature field to be respected (not replaced with a 65B signature), but for (atleast parts of) the signature passed in to be incorrect as the transaction's gas_limit is modified during estimation

[hbriese]

@MexicanAce

[MexicanAce]

Thank you for the ping (apologies for not responding sooner). Understood, and I'll bring this up internally to better understand the limitations here.