Open dylanjw opened 6 years ago
what is the effect of inserting dummy values for v, s and r in the context of gas estimation? Im hoping none.
Should be minimal depending on what else you spoof. Looking into what happens when transactions get validated is probably the right place to start here.
Is this overdoing it
As long as our mechanism for gas estimation appropriately handles things like gas refunds, base transaction gas costs, etc, I'm fine with whatever approach we choose.
I think if the transaction execution refactor in: https://github.com/ethereum/py-evm/pull/383 could include an entrypoint to pass a message rather than a transaction, it would be pretty easy to implement a call
method to use in the gas estimation.
Can that be done by just manually constructing the message
instance and then manually calling executor.run_computation -> executor.run_post_computation
with the message
instance?
What is wrong?
Gas estimation should not require a signed transaction. An example use case is getting a gas price estimate for transactions before local signing, where the private key is not available to the node.
How can it be fixed
The instance of
SpoofTransaction
can be extended to provide the rest of the missing attributes from an unsigned transaction object. The following stack trace + exceptions show each dependent attribute that would need to be added to SpoofTransaction when passing an unsigned transaction object. Note, Im passing in a SpoofTransaction object to chain.Chain.estimate_gas(), adding override attributes one at a time to get all required attributes:instrinsic_gas
get_sender()
s
,r
, &v
invalidate_transaction
sender
Im unsure if this approach will break anything. A few questions I have: