[CLOSED] Kernel: add 'isLocalCall' logic into avm transaction processing

[aionbot]

Issue created by aionick (on Friday Nov 23, 2018 at 18:30 GMT)

The kernel has the concept of a local call, which is meant to be a false call that should produce no state changes or public footprint and that originates in the API layer.

An example of such a call is the API call eth_estimateGas which is meant to produce a reliable estimate of how much energy your transaction will actually consume - this problem is solved by actually running the transaction once and not allowing any state changes to persist and immediately dropping it once it is run, and using its energy consumption as the response.

Since we are at the point where we are using the web3 API we might as well implement this last detail to be fully compliant.

However, I do not believe this local call concept should leak into the Avm at all, that seems like bad design ... this is a kernel concept, and actually it is only an implementation detail, not even a high-level detail. This should be fairly easy to accomplish, however, so long as we provide some faked-up guaranteed-to-pass values (from our KernelInterface) for energy limit, nonce, balance so that all of these checks will always succeed inside the avm, and then so long as we do not publish the write logs that the Avm hands back to us.

[aionbot]

Comment by aionick (on Friday Nov 23, 2018 at 20:47 GMT)

I've decided not to go the way of publishing 'fake' values to the Avm in order to force the nonce etc. checks to pass because an undesirable side-effect of this is that this fake value gets used for the duration of the run as the real value.

What we want is to separate the checks from the querying of the values. A natural solution is to move these checks to be the responsibility of the KernelImplementation, this way the Avm can continue to perform them inside its world but the actual logic behind the checks is injected into the Avm as the kernel wishes.

[aionbot]

Comment by aionick (on Monday Nov 26, 2018 at 14:42 GMT)

This issue is about to be closed but there is something I want to look into a bit further when I get a chance... the fvm used to handle this case by doing all the things listed above but also NOT deducting the energy cost at the start of the transaction.

It seems to me this is only an "optimization"? Since we know we won't be refunding or saving state, we can just avoid this? Besides this, I can't think of any other reason to skip this step...

I am choosing not to skip it for now because it can be misleading: with the old scheme if you do not have sufficient funds to cover the energy costs you won't know, you can still fully run the transaction and potentially succeed.

[aionbot]

Comment by aionick (on Monday Nov 26, 2018 at 14:52 GMT)

Closed by the kernel commits: c59d90327226a539340383c3df3f0e5b0c6ab9f9 eb52caa382f6aecca5e2dd3fd3d406b241d76d2b