Fixes #251 better way for dynamic gas estimation #252
Conversation
|
#229 covers this same functionality. The idea there was calling the EVM directly at rpc-level, without spawning a runtime instance per binary search iteration. As per @sorpaas suggestion, we closed it (temporarily) and go back to it once we add schema versioning for the I leave up to him to decide what to do with this one. (Also sorry for the inconvenience). |
It's fine. #229 looks pretty complex comparing to the goeth implementation. It's less risky using the simple one ;-) |
Starting https://github.com/paritytech/frontier/pull/229/files#diff-f5b58703c6605ce51568c53912a42386c530956f2f22e15c0a4bcaa4bdfbdf65R110 , uses the same approach as in the goeth implementation. The rest is a draft for interacting with the EVM directly at rpc-level. |
|
@werlandy Just wonder if you can try rust-ethereum/evm@5902295 and see whether it fixes the problem? I think we'd want to include binary search as an option for the RPC, but in the mean time I want to treat all estimation failures as bugs. |
|
Hi Wei
I just use a simple case to test its functionality. The smart contracts I used are:
pragma solidity ^0.5.16;
contract Demo1 {
uint public data;
function setData(uint _data) public {
data = _data;
}
}
contract Demo2 {
function toSetData(Demo1 demo1, uint _data) public {
demo1.setData(_data);
}
}
I called estimateGas on the toSetData function in Demo2. The solution you mentioned gives an estimation of 67152102 and gas used of 1092489. However the expected gas estimation should be 43879, and gas used should be 43603.
…------------------ 原始邮件 ------------------
发件人: "paritytech/frontier" <notifications@github.com>;
发送时间: 2021年1月5日(星期二) 晚上10:41
收件人: "paritytech/frontier"<frontier@noreply.github.com>;
抄送: "霰雪无垠"<422606101@qq.com>;"Mention"<mention@noreply.github.com>;
主题: Re: [paritytech/frontier] Fixes #251 better way for dynamic gas estimation (#252)
@werlandy Just wonder if you can try rust-ethereum/evm@5902295 and see whether it fixes the problem?
I think we'd want to include binary search as an option for the RPC, but in the mean time I want to treat all estimation failures as bugs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@werlandy The code is okay, but the naming right now is not. The main issue is that we can't randomly introduce a new RPC method in the Would you mind do the following:
|
|
Sure, good suggestion. Will make the change :)
…------------------ 原始邮件 ------------------
发件人: "paritytech/frontier" <notifications@github.com>;
发送时间: 2021年1月7日(星期四) 晚上11:26
收件人: "paritytech/frontier"<frontier@noreply.github.com>;
抄送: "霰雪无垠"<422606101@qq.com>;"Mention"<mention@noreply.github.com>;
主题: Re: [paritytech/frontier] Fixes #251 better way for dynamic gas estimation (#252)
@werlandy The code is okay, but the naming right now is not.
The main issue is that we can't randomly introduce a new RPC method in the eth_ namespace. They're designed not with client extensions but go through the EIP process.
Would you mind do the following:
Create an rpc_binary_search_estimate rust feature (you can decide the name).
Make the code so that when the feature is enabled, use your new code. Otherwise, use the old code.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@sorpaas As suggested, I've added the "rpc_binary_search_estimate" feature, and code was well tested by different cases. You can decide whether to enable the feature in node template later. |
Fixes #251
Currently Frontier's gas estimation rpc call returns the actual gas used,
however gas estimation on Ethereum is a complex problem,
sometime we need to give a higher gas limit than the actual used,
otherwise the transaction may fail.
We provide a test case. There are two contracts,
and contract 2 will invoke method of contract 1 to update its state.
Using frontier, the estimated gas is 43603, however it needs a minimum gas limit of 43879.
We use a binary search based dynamic gas estimation strategy to solve the above issue，
and the strategy is also used by go-etherem
(ethereum/go-ethereum@682875a)