Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Calculate gas for deployment transaction #9840

Merged
merged 3 commits into from
Nov 28, 2018
Merged

Conversation

grbIzl
Copy link
Collaborator

@grbIzl grbIzl commented Oct 31, 2018

Gas for the deployment transaction for the private contract was overestimated. More accurate method with client.estimate_gas implemented.
Closes #9708

@grbIzl grbIzl added A0-pleasereview 🤓 Pull request needs code review. M4-core ⛓ Core client code / Rust. labels Oct 31, 2018
Copy link
Collaborator

@sorpaas sorpaas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that Client::estimate_gas would have to execute the transaction, so with this change we're probably executing private transactions twice, which can slow things down noticeably. On the other hand, having overestimated gas would probably do no harm if the contract is somewhat "trusted", or if we need a successful execution of the code anyway.

.and_then(|h| h.decode().map_err(|_| ErrorKind::StateIncorrect).into())?;
let (executed_code, executed_state) = (executed.code.unwrap_or_default(), executed.state);
let tx_data = Self::generate_constructor(validators, executed_code.clone(), executed_state.clone());
let gas = match self.client.estimate_gas(&Transaction{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: missing space

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the deployment transaction the speed is not so important as it's one-time action. At the same time overestimation for the gas can (and actually is, see the corresponding bug) cause problems as wrapper contract is pretty complex and stores private contracts inside. In case, when the private contract is big enough, this overestimation exceeds gas_limit.

@5chdn 5chdn added this to the 2.3 milestone Nov 1, 2018
Copy link
Contributor

@andresilva andresilva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know a lot about private transactions to have any strong opinions regarding what @sorpaas mentioned but Client::estimate_gas may need to execute the transaction more than once (since we do a binary search for minimum gas required). If we want to stick with the naive estimate we could cap it to the maximum gas limit to fix #9708.

gas_price: gas_price,
value: source.value,
data: tx_data.clone(),
}.fake_sign(sender),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I think indentation is a bit weird like this

@grbIzl
Copy link
Collaborator Author

grbIzl commented Nov 12, 2018

@andresilva yes, usage of max_gas will address the issue, but IMHO such solution will damage "informativeness" of this API call (I mean, create deployment transaction method). Right now this call returns estimation for the gas and it makes a lot of sense since it may be totally unclear for the external user, how much gas it can take (because a lot of things hidden under the hood). At the same time, as I've already explained, this call is one-time action and will be done only once during system setup. So IMHO the performance is less important here, than the mentioned "informativeness"

@andresilva
Copy link
Contributor

@grbIzl Sorry for not moving this PR forward, I pushed a commit to fix the style nit, approve and merge if you agree 👍.

@sorpaas
Copy link
Collaborator

sorpaas commented Nov 27, 2018

@grbIzl I still worry about use cases such as chains that may want to deploy new private transaction account for every user. In those cases we potentially can have a lot of deployments! I understand that probably no one uses it like that currently, but it indeed feels feasible to have this use cases in certain situations, and just want to make sure we don't shot ourselves in the foot!

  • If we use Client::estimate_gas, it may be slow for them. And for those users there's probably no way to opt out if this is a bottleneck.
  • If we just increase the current gas cap estimate. For users that do need the informativeness of estimated gas, they can take the transaction payload, feed it to eth_estimateGas and get what they want. For users that just want to get the payload and deploy things fast, it won't affect them.

Copy link
Collaborator

@sorpaas sorpaas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed with @grbIzl. Looks like this change only affects compose_deployment_transaction RPC call. While not strictly required, most common use cases would need to estimateGas anyway. So the current solution might just be the best one!

@5chdn 5chdn added A8-looksgood 🦄 Pull request is reviewed well. and removed A0-pleasereview 🤓 Pull request needs code review. labels Nov 28, 2018
@5chdn 5chdn merged commit 7f5e6b3 into master Nov 28, 2018
@5chdn 5chdn deleted the PrivateContractGasEstimation branch November 28, 2018 12:14
niklasad1 pushed a commit that referenced this pull request Dec 16, 2018
* Calculate gas for deployment transaction

* Space fixed

* ethcore: style fix in public_creation_transaction
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A8-looksgood 🦄 Pull request is reviewed well. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants