Support post EIP1559 tx types for RPC

[shresthagrawal]

Current eth_estimateGas and eth_call do not support the post EIP1559 tx types

[acolytec3]

I halfway fixed this out of necessity in #2316 but will need to be cleanly implemented in a separate PR. A minimal implementation will update this line to use TransactionFactory and also possibly update the RpcTx type to include maxFeePerGas and maxPriorityFeePerGas. Also, coming out of experience in with Shandong testnet, we should decide what to do with transactions that don't include any gasPrice or maxFeePerGas fields. In Shandong, we opted to just use the latest block's base fee as a reasonable default.

[g11tech]

@acolytec3 should the eth_call directly do runTx than calling the vm's runCall?

[acolytec3]

@jochem-brouwer any thoughts here? I can test it out but conceptually switching the logic of this handler to use TransactionFactory.fromTxData and then calling runTx would accomplish the same net effect, right? And that would be easier than rebuilding similar logic to handle the different transaction types that get passed in here.

[acolytec3]

Maybe I can take a stab at this in the Shandong branch and see how it goes. It certainly limits the usability of our RPC if eth_call only supports legacy txns.

[jochem-brouwer]

Yes that should work!

[acolytec3]

Cool. I'll add it to my proofs of concept in shandong and we can pull out in separate PRs against master of everything goes well

[acolytec3]

I believe this is closed by #2411. @shresthagrawal care to take a look at our latest master and verify if it meets your needs?

[holgerd77]

I believe this is closed by #2411. @shresthagrawal care to take a look at our latest master and verify if it meets your needs?

@acolytec3 the PR you are referencing seems to not fix the eth_call part mentioned in the issue description. Is this also fixed? If so, any reference on this as well?

[acolytec3]

After I reviewed the eth_call documentation more closely, it turns out it doesn't have any concept of transaction types at all. If you look at the description of the transaction object in the input parameters, it exactly matches what we already have implemented. eth_call mimics our evm.runCall more closely than vm.runTx so I think what we currently have in place is correct.

[acolytec3]

Should be addressed at this point.