ethers.js calling gasPrice once again for BSC

[tornadocontrib]

Describe the Problem

Fixed by #4686

[mahatotarit]

The result changes depending on which network you use.

Example -

const ethers = require('ethers');

async function getGasPrice() {
    const provider = new ethers.providers.JsonRpcProvider('https://bsc-dataseed.binance.org/'); // For BSC network

// const provider = new ethers.providers.JsonRpcProvider('https://mainnet.infura.io/v3/YOUR_PROJECT_ID');  // For ethereum main network

    const gasPrice = await provider.getGasPrice();
    console.log("Current gas price:", ethers.utils.formatUnits(gasPrice, 'gwei'), "gwei");
}

getGasPrice();

[ricmoo]

Yes. The gas price depends on network; that’s just how gas works. :)

Ethereum uses EIP-1337, so the fees are protocol defined (based on recent block congestion).

BSC uses a bidding system, so the miners choose the gas price based on what a transaction is willing to pay.

[tornadocontrib]

@mahatotarit @ricmoo Yes, but the problem is that current code will just send request to node even when I already specify the gasPrice and it is odd since when there is already a gasPrice ethers.js wouldn't apply it so why sending an additional request when we wouldn't override them?

[ricmoo]

@tornadocontrib I agree that is something I will optimize. My previous comment was regarding the comment by @mahatotarit.

I’m working on it. It just takes time. :)

[tornadocontrib]

@ricmoo BTW, is there any specific reason to block "from" field for Transaction.from method?

I think it would be helpful to restrict transaction being signed by a specific signer but don't know if it would be appropriate.

[ricmoo]

@tornadocontrib You can specify from in a TransactionRequest, but the Transaction is a living object; so the from is calculated from the tx details and the signature.

For example, when you set the value, then getting the .serialized now contains the updated value. What would it mean if you set the from field? It would require that the signature be updated, which would require the private key, which a Transaction doesn’t (and shouldn’t) have.

The key thing to keep in mind is that there isn’t actually a from in a transaction. The JSON-RPC includes it as a hint to the client, but the tx from address is computed via ecrecover, so it is entirely an implied property. But that’s why other Transaction-ish objects (like TransactionRequest and TransactionResponse) include it. :)

Does that make sense?

[tornadocontrib]

@ricmoo Yes, didn't notice since I haven't read the full codebase but thanks for clarification, was working on the transaction serialization for offline signing though.